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"With iPods and iPads and Xboxes and PlayStations -— none of which | know 
how to work - information becomes a distraction, a diversion, a form of 
entertainment - rather than a tool of empowerment, rather than the means of 
emancipation... All of this is not only putting new pressures on you, it is 
putting new pressures on our country and on our democracy." 


——— May 9, 2010 quote from a commencement speech Obama gave at Hampton 
University. Information a distraction? | thought information was power? Or is there 
something out there Obongo doesn't want exposed? Oh, and Mr. Constitutional 
Lawyer, the United States is a republic, not a democracy. 
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4-wire No. 1 ESS. The function of the maintenance 
programs is to keep the system operating in the 
presence of trouble, to localize trouble for maintenance 
personnel, and to guard against the accumulation 
of undetected troubles or of uncorrected errors 
that might affect the traffic handling capability of 
the system. 


1.02 A telephone switching system must provide 

continuous and accurate service without 
unreasonable delays. This quality of service must 
be provided 24 hours a day throughout the design 
life of the system. Thus a successful system must 
be both dependable and maintainable. Dependability 
is defined as a measure of service continuity and 
accuracy; maintainability is defined as a measure 
of the ease with which the component failures can 
be detected, located, and repaired. 


1.03 The use of high-speed data processing circuits 

in the No. 1 ESS has brought about an 
increase (as compared to earlier switching systems) 
in the time sharing of circuits and consequently in 
the centralization of the control functions. This 
centralization has many advantages, but it can 
make the system more vulnerable to component 
failures. For example, if no redundancy is provided, 
it would be possible for a single component failure 
in the central control to cause a complete system 
failure. 


1.04 The No. 1 ESS is at least as dependable 
and easy to maintain as the existing 
electromechanical switching systems. The objectives 
for dependability are that the system down time 
should not exceed three minutes per year and that 
the calls handled incorrectly should not exceed 
0.002 percent. The objectives for maintenance 
require that the troubles can be located and repaired 
easily and rapidly and that the system can be left 
unattended for extended periods of time. 


1.05 The No. 1 ESS maintenance plan is 

implemented partly by circuits and partly 
by programs. Some maintenance functions can be 
performed by either the circuits or the programs. 
Trouble detection is a function that requires 
continuous attention and is, therefore, usually better 
suited to circuits than to programs so that system 
real time is not used for this function. There are 
some instances where programs can accomplish 
the detection function more effectively than circuits. 
For example, faults in the circuits that are used 
with duplicate units might be likely to go undetected 
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until the circuit is needed. To avoid undetected 
faults, programs called routine exercises test for 
trouble in circuits that are not frequently used. 
These routine exercises may be initiated automatically 
by the system or they may be requested via the 
teletypewriter by maintenance personnel. 


1.06 There are five classes of No. 1 ESS programs. 
In order of urgency, these classes are as 
follows. 


(1) Programs that recover the system data 
processing ability. These programs operate 
at levels A through E interrupts. 


(2) Programs that recover proper operation of 
the peripheral system. These programs 
operate at a level F interrupt. 


(3) Programs that localize faults within a system 

unit that contains troubles but may or may 
not pass diagnosis. These programs operate at 
levels B and K interrupts. 


(4) Programs that handle inputs and outputs. 
These programs operate at levels H and J 
interrupts. 


(5) Programs that process calls within the 
system. These call processing programs 
operate at the base level (level L). 


1.07 There are two basic types of maintenance 
programs: interrupt programs and noninterrupt 
programs. 


(a) Interrupt maintenance programs are initiated 

by trouble detection circuits. These circuits 
alert the central control which interrupts the 
call processing programs. The interrupt initiates 
a fault recognition program which is nondeferrable 
and which must be completed before call processing 
can be resumed. The fault recognition program 
determines which system unit has failed, removes 
the faulty unit from service, switches to a 
duplicate unit, records the failure in the call 
store area reserved for subsystem status, and 
returns control to the call processing programs. 
Fault recognition programs are usually brief 
enough so that they do not interfere with normal 
call processing. 


(b) Noninterrupt maintenance programs include 
diagnostic programs, routine exercise programs, 
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audit programs, and deferrable fault recognition 
programs. These programs are performed under 
the control of the maintenance control program 
and the maintenance control register. The 
maintenance control program periodically checks 
the maintenance control register in the subsystem 
status area of the call store to determine whether 
a noninterrupt maintenance program is required. 
When the maintenance control program starts a 
maintenance program, that maintenance program 
is called the client program or the client of the 
maintenance control register. 


1.09 Definitions of terms and abbreviations used 


in this section are as follows. 


(a) Fault—A recurring trouble (a malfunction 
that can be consistently reproduced). 


(b) Error—A nonrecurring trouble. 


(c) Interrupt—A seizure of control by the 

central control from a program being executed 
for the purpose of giving control to another 
program that is more urgent. 


(d) Noninterrupt—A low-priority request that 
central control acts on when time is available. 


(e) Recovery—Regaining the ability to process 
calls and to perform other normal functions 
in spite of a malfunction. An example is the 
substitution of standby equipment for active 
equipment that is not functioning properly. 


(f) Routine Exercise—Periodic programmed 

routines whereby the system tests its own 
ability to perform properly and detects faults 
before system operation is affected. 


(g) Audit—A check on the validity of the state 

of the system. In particular, a call store 
audit consists of a check on the correctness of 
information in some storage locations and of the 
correction of invalid information. The contents 
of the storage locations checked are compared 
with information in other call store locations or 
with information in the program store. 


(h) Deferrable—An operation that can be 

performed when system time is available. 
Deferrable operations do not interrupt operations 
in process. 
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(i) Nondeferrable—An urgent operation that 
must be performed immediately to restore 
system operation in the event of a major failure. 
Operations in process are interrupted until a 
nondeferrable operation is completed. 


(j) MAC—The maintenance control program 

that controls and administers various deferrable 
maintenance programs specified in the maintenance 
control register (MACR). The specified maintenance 
program is called the client program. 


(k) MACR—The maintenance control register 

that stores requests for deferrable maintenance 
program operations. The MAC program interrogates 
the MACR to determine which maintenance 
program to initiate. The maintenance program 
then started under control of the MAC program 
is called the client of the MACR. 


2. ACTIONS BY MAINTENANCE PERSONNEL 


2.01 When a diagnostic program discovers a 

failure, the system leaves the equipment 
frame containing the fault out of service. In order 
to alert maintenance personnel to an existing fault, 
the system 


(a) Sounds an audible alarm 


(b) Lights the pilot lamp for the aisle containing 
the faulty frame 


(c) Lights the out-of-service lamp on the control 
panel of the equipment frame containing 
the fault 


(d) Lights the appropriate MAJOR or MINOR 
alarm lamp on the alarm, display, and control 
panel of the master control center 


(e) Lights a lamp on the alarm, display, and 

control panel of the master control center 
to indicate which type of equipment frame 
contains the fault 


(f) Prints the frame identification and the 
diagnostic results at the maintenance 
teletypewriter. 


2.02 The relationship of maintenance programs, 


trouble detection circuits, and maintenance 
personnel is summarized in Fig. 1. 
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Fig. 1—Maintenance Program Reaction to Trouble 


3. RECOVERY FROM TROUBLE 


3.01 Circuit troubles are detected by fault detection 

circuits or, when a network controller or a 
trunk circuit produces an abnormal response, by 
call processing programs. When trouble is detected, 
program control is usually transferred immediately 
to programs that recover the call processing capability 
of the system. These programs are called fault 
recognition (FOR) programs. 


4. FAULT RECOGNITION PROGRAMS 
4.01 The purpose of the FOR programs is to 
re-establish the call processing ability of 


the system. This is accomplished by removing 
the faulty unit from service and by requesting a 
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diagnosis of the unit. The FOR programs are 
usually nondeferrable and have the highest priority 
of the system programs. Also these FOR programs 
can be used as deferrable programs. ; 


4.02 A typical FOR program carries out the 
following tasks: 


(1) Determines whether the trouble detected 

was an error (a transient malfunction that 
can no longer be reproduced) or a fault (a 
reproducible malfunction that can be diagnosed) 


(2) Identifies the faulty system unit and takes 
it out of service 


(3) Records a request for a diagnosis of the 
faulty unit 


(4) Records all pertinent error or fault information 
(5) Returns the system to normal call processing. 


4.03 Interrupt sources within the system are 

divided into ten levels that are designated 
A through K (excluding I) from highest to lowest 
priority (Table A). An interrupt source of a given 
level can override any interrupt source of a lower 
level. The priority level of the main program is 
called the base level or level L. 


TABLE A 
INTERRUPT LEVELS 


Master control center (manual 
control) 


Emergency action 
CC mismatch 

CS reread failure 
PS reread failure 


Improper operation of the peri- 
pheral system 


Error evaluation and special 
programs 


5-millisecond interrupt 


Signal processor (2-wire only) 


4.04 The interrupt level provides a rough isolation 

of trouble by indicating what type of unit 
contains a fault. A separate FOR program is 
initiated by each of the levels B through E interrupts 
(Fig. 2). The level F interrupt has many sources; 
a filter program selects the proper FOR program. 


4.05 When the FOR program has established a 

fault-free configuration, the FOR program 
transfers control to a restart program which 
determines whether the condition of the system 
justifies a return to call processing either at the 
point where it was interrupted or at a reference 
point that does not depend on past history. The 
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return to a reference point is necessary in such 
cases as when a central control (CC) mismatch was 
caused by an error and the system has no way of 
determining which CC was wrong. 


4.06 The relationship between programs shown 

in Fig. 2 is incomplete. For example, a CC 
mismatch may be due to a malfunction in a program 
store or a call store, in which case a transfer is 
made to the appropriate FOR program. 


EMERGENCY ACTION 


4.07 The emergency action program (PD-1A010) 

is activated by certain checks on programs 
(for example, by failure to complete E-to-E base 
level cycles in a given amount of time) or by an 
excessive rate of maintenance interrupts. The 
emergency action program is divided into phases 
which are executed until an operational memory is 
obtained (Part 12). With each phase more and 
more call store memory is initialized until, with 
phase VI (initiated manually only), even the recent 
change memory is initialized. The emergency action 
is a backup for the normal recovery facilities and 
should occur very infrequently in normal system 
operation. 


CENTRAL CONTROL FAULT RECOGNITION 


4.08 During system operation two CCs are running 

in step: one designated active and the 
other standby (synckronously executing the same 
instruction). Cross-connection circuits continuously 
match the data in these two CCs running in step. 
A malfunction in either CC causes a mismatch 
which initiates a level C interrupt and a transfer 
of program control to the start of the central 
control-fault recognition (CC-FOR) program. The 
primary objective of this program is to determine 
whether the mismatch was caused by a permanent 
fault in one of the CCs or by a transient error. 
If a permanent fault is detected, the CC is removed 
from service and a diagnostic is requested. 


4.09 The CC-FOR program (PD-1A015) functions 
are as follows: 


(a) To qualify the CC trouble indication (mismatch) 
as transient malfunction (error) or reproducible 

malfunction (fault) 

(b) To isolate the fault (if any) to the active 
or to the standby CC 
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Fig. 2—Initiation of Fault Recognition Programs 
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(c) To remove the faulty CC from service and 
to substitute the standby for the active CC 
if necessary 


(d) To request a diagnostic of the faulty CC 
when necessary 


(e) To record pertinent CC error and fault 
information 


(f) To initiate actions required to return the 
system to normal operation at the conclusion 
of the program. 


4.10 To distinguish a fault from an error, test 

exercises are executed by the CCs. Failure 
of any of these exercises indicates a fault. If all 
the exercises pass the tests, the malfunction is 
considered an error (not reproducible). 


4.11 Isolation of the faulty unit is accomplished 

by conditional transfer orders in the test 
exercises and in the CC match circuits. A typical 
test is the operation on data within the CC and is 
followed by a conditional transfer order based on 
the result of this operation. If the proper decision 
is made by the active CC, it passes the test. If 
the active CC passes the test and the standby CC 
has not made the proper decision, a mismatch is 
detected and the standby CC fails the test. 
Consequently, the two objectives of distinguishing 
a fault from an error and of isolating the faulty 
unit are met simultaneously. 


4.12 The CC-FOR first-look program tests the 
CC hardware that most likely caused the 
mismatch. When the mismatch is detected, 
information is saved within the CC to define the 
hardware being matched at that time and the class 
of instruction being executed. This information is 
then used by the CC-FOR program to decide which 
CC tests to run. For example, if the mismatch is 
detected at the index adder output register, part 
of the CC-FOR program tests the index adder 
circuitry, the registers, and the buses which have 
access to the index adder. If these tests are 
passed, it is assumed that the mismatch was 
generated by an error rather than a fault. 


4.13 The complete CC-FOR program serves as a 

backup to the first-look program and is used 
either when it appears there are CC faults not 
being detected by the first-look program or when 
abnormal conditions exist. This CC-FOR program 
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is time consuming and is used only when there are 
strong indications that a fault exists in one CC. 


CALL STORE FAULT RECOGNITION 


4.14 The call store-fault recognition (CS-FOR) 
programs (PD-1A018) perform the fault 
recognition task for the CSs assciated with CCs 
(CC-CS), the CSs associated with signal processors 
(SP-CS), the related bus systems, and the circuits 
in the CCs and SPs associated with either or both 
bus systems used to communicate with the CSs. 


4.15 The CS-FOR programs restore, or recover, 
call processing capability by switching various 
CS units and buses until a workable CS configuration 
is established. The CS-FOR programs also determine 
if further action by the diagnostic programs is 
required to analyze trouble in a subsystem. 


4.16 The programs are divided into recovery and 

deferred phases. Programs executed during 
an interrupt are called recovery phases. The system 
does not handle telephone calls while the recovery 
phases are in process. Therefore an operational 
system configuration must be established as soon 
as possible. 


4.17 In addition to recovering an operational 

system configuration, the CS-FOR programs 
isolate the faulty units. The isolation programs 
are called the deferred phases. During these 
phases, the CS-FOR” program determines which 
subsystems contain faults. Faulty subsystems are 
switched out of service, and diagnosis of faulty 
units is requested. The deferred portion of the 
CS-FOR program is interleaved with call processing 
programs; therefore, telephone calls are handled 
while faults are being isolated. 


4.18 Each CS contains circuits for checking its 
operation. The CC also contains circuits 
for checking the operation of the complex of CSs 
and CS buses. Conditions detected by these 
maintenance circuits result in bringing the CS-FOR 
programs into operation whenever necessary. 


4.19 ACS generates an all-seems-well CS (ASWC) 

signal if it passes certain internal checks 
during an operation. The ASWC signal is a summary 
of internal checks made by the CS circuits, Generation 
of the ASWC signal is inhibited to inform CC that 
the CS has not functioned properly. When CC does 
not receiver the ASWC signal, it requests a CS 
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reread. If the CS reread also fails, a level D 
interrupt occurs. This interrupt causes a wired 
transfer to the CS-FOR program. Further processing 
of calls is delayed until a workable CS configuration 
is established. 


4.20 The CC also calculates a parity bit over the 

address and the data word that are written 
into the CS memory. The parity bit is stored in 
the memory as bit 23 of the 24-bit CS word. When 
CC reads the word out of the memory, it checks 
parity. If the parity check fails, a CS reread 
occurs. 


4.21 Failures that are not detected by the ASWC 

check and the parity check are detected 
when the duplicate copies of CS information are 
matched by the two CCs. Failure of one copy 
causes a mismatch that leads to a level C interrupt. 
The CC-FOR programs then transfer control to 
the CS-FOR programs. 


4.22 Following a level D interrupt, the interrupt 

control program is entered. This program 
consists of the first-look, the access test, and the 
bootstrap subroutines. 


4.23 The first-look subroutine is used to attempt 

a quick recovery of the system. This 
subroutine uses the address of the failure (stored 
in the CC) and the states of the system bus control 
flip-flops to determine what CC-CS bus configuration 
was in use at the time of the failure. From this, 
the subroutine determines which CS failed and 
removes that CS from service. It then adjusts 
the bus control flip-flops of the duplicate CS so 
that it can supply the duplicate information. 


4.24 The access test subroutine checks that an 

operational system exists by addressing and 
by getting return readouts from each information 
block in the CS system. If the access test is 
successful, the CC-CS complex is considered 
operational and call processing is restarted. If 
the access test fails, the first-look recovery was 
not successful and the interrupt control program 
calls in the bootstrap subroutine. 


4.25 The bootstrap subroutine attempts to recover 

an operational CC-CS complex on one bus 
system. The standby bus is checked later during 
the deferred phase of CS-FOR program. Two 
levels of operation are provided to obtain the CC-CS 
configuration. First, only CSs which were in service 
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at the time of the interrupt are tested. If an 
operational configuration cannot be obtained from 
these CSs, then all CSs are tested. The configurations 
for the sequences of switching during bootstrap 
recovery are shown in PF-1A018. If the bootstrap 
subroutine cannot recover the system, no automatic 
recourse exists. 


PROGRAM STORE FAULT RECOGNITION 


4.26 The program store-fault recognition (PS-FOR) 

programs (PD-1A120) are concerned with 
operating irregularities which require testing of 
PSs, buses, and/or associated equipment. The 
PS-FOR program is entered after a PS reread 
failure interrupt. 


4.27. The PS-FOR program performs the following 
operations. 


(a) Determines whether the trouble is a fault 

or an error. (A trouble is classified as a 
fault if the tests conducted during the fault 
recognition sequences reproduce the trouble 
indications or generate new trouble indications; 
otherwise, the trouble is an error.) 


(b) Identifies any faulty subsystem, removes 
the unit from service, and requests appropriate 
diagnostic programs. 


(c) Reconfigures interconnections among fault- 
free equipment where necessary to create a 
workable overall system configuration. 


(d) Updates status records for all subsystems. 


(e) Records pertinent error data and analyzes 

this data to determine whether some particular 
subsystem is marginal. If such a marginal unit 
is found, the program treats it as faulty. 


(f) Returns the system to call processing within 
a few milliseconds after the interrupt occurs. 


CENTRAL PULSE DISTRIBUTOR FAULT RECOGNITION 


4.28 The central pulse distributor fault recognition 

(CPFR) program (PD-1A022) is entered 
whenever a peripheral (level F) interrupt occurs. 
Such an interrupt occurs if the maintenance check 
of a peripheral instruction fails and the level F 
interrupt pest control flip-flop in the buffer bus 


register of the CC has not been set to suppress 
the interrupt. 


4.29 If the interrupt occurred on a peripheral 

address, a retry of the instruction is normally 
performed to determine whether the trouble is 
transient or whether a fault exists. If the retry 
passes, peripheral error counters are incremented 
and a teletypewriter message with details of the 
error is printed out. If the error occurred during 
supervisory scanning, the scanner enable route is 
changed to select a new bus and a controller. This 
is done because the retry of a supervisory scan 
instruction may address a different row from the 
one that failed. Changing the scanner enable route 
is likely to switch out the trouble. 


4.30 If the retry failed, the program attempts 

to isolate the source of trouble by trying 
again with a different central pulse distributor 
(CPD) and CPD bus configuration. If a good 
configuration is found, the system routing information 
is updated and diagnosis of the faulty subsystem 
is requested. Call processing is then resumed. 


4.31 If a working configuration is not found, the 

program determines whether a scan order 
failed. If a scan order did fail, the CPFR program 
transfers control to the scanner FOR program for 
further investigation. Otherwise, a switch of CCs 
is requested since a translator or a cable pulser in 
CC could be at fault. 


4.32 The error retry procedure does not occur if 
the interrupt occurs during a network 
instruction or a signal distributor instruction. In 
these instances, control is transferred directly to 
the network FOR program. In the event of an 
enable verify mismatch wherein two frames return 
verify signals, the noisy frame and the controller 
are determined from the verify answer signal. A 
message identifying the noisy frame is printed out 
so that power can be removed from that frame. 
The CPD that has been active at the time of the 
mismatch is switched out to prevent further 
mismatches in case the CPD is at fault. 


SCANNER FAULT RECOGNITION 


4.33 When the CC addresses a scanner (PD-1A026), 

certain responses are expected from the 
scanner and the CPD to indicate that the instruction 
has been successfully executed. These responses 
include the enable verify signal which indicates 
that the proper peripheral frame had been enabled 
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and the all-seems-well scanner (ASWS) signal which 
indicates that the scanner has sent back answers 
from one and only one row of scan points. If these 
responses are absent, a level F interrupt occurs 
and the CPFR program is entered. To filter out 
transient errors, the CPFR program retries the 
instruction that failed. If the trouble indication 
persists, the CPFR program checks the type of 
instruction and checks the failure indications to 
determine whether scanner trouble exists. If the 
scanner is at fault, control is transferred to the 
scanner fault recognition program (SCFR). 


4.34 The SCFR program attempts to find a 

working configuration of a peripheral unit 
bus, a CPD, a scanner controller, and an answer 
bus by retrying the failing instruction with various 
combinations of these subsystems. If a good 
configuration is found, the SCFR program requests 
diagnosis of the scanner and updates the appropriate 
route information so that the faulty configuration 
is switched out. Also the appropriate trouble 
lamp corresponding to the type of scanner is lighted 
at the master control center. 


4.35 If a good route is not found after all 

configurations have been tried, a validity 
check is made on the scanner instruction to determine 
if it contains a legitimate scanner enable address 
and to determine if a scanner translator is specified 
for decoding the scanner row address. If the 
validity check fails, the program transfers to a 
routine to regenerate,the route tables from backup 
information in the PS. If the validity check passes, 
a bad CC, an open scanner row, or a double 
trouble is indicated. To handle these contingencies, 
the appropriate primary trouble lamp is lighted at 
the master control center; the CCs are switched; 
the scanner diagnosis is requested; and the ASWS 
request bit is set to 0. With the ASWS request 
bit zeroed, the system can run without level F 
interrupts in supervisory scanning. The ASWS 
request bit is restored to 1 if the scanner passes 
the diagnosis. 


NETWORK AND SIGNAL DISTRIBUTOR FAULT 
RECOGNITION 


4.36 In order of priority, the network and signal 
distributor fault recognition (NMFOR) program 
(PD-1A028) has the following purposes: 


(1) To recognize and to record malfunctions of 
network controllers or signal distributors 


(SDs) 
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(2) To utilize standby duplicate units in order 
to find a workable configuration for completing 
the requested peripheral action 


(3) To alter the master enable tables, thus 

directing the system to use the best possible 
configurations of network controllers, SDs, 
peripheral unit buses, and CPDs 


(4) To take requested failure action on failing 
orders 


(5) To request diagnostic action on suspect 
peripheral units 


(6) To inform maintenance personnel of failures 
to transfer supervision on network actions 


(7) To administer a. linked list of requested 
switching actions involving network and SD 
units 


(8) To provide certain services to client programs 

(chiefly the network and the SD diagnostic), 
such as sending diagnostic orders, timing delays, 
and recording data. 


4.37. The network consists of the fabric and the 

controllers. The fabric through which talking 
and signaling paths are set up is the actual body 
of switches and links. The controllers are logical 
circuits which serve as interface between the CC 
or the signal processor and the fabric. When some 
change in the fabric is requested by the CC or 
the signal processor, an appropriate order is sent 
to the proper network controller via the peripheral 
unit bus. The controller decodes the order and 
performs the requested function by actually opening 
or closing the desired ferreed switches or the relay 
contacts in the fabric. For the purpose of fault 
recognition, some internal checks are provided on 
controller operations. Assigned to each controller 
for the purpose of fault recognition are master 
scanner points F, S, and T that monitor the states 
of the F, S, and T flip-flops. The combination of 
the states of these flip-flops specifies the condition 
of the controller. Malfunctions in the controller 
circuitry are indicated by its failure to cycle properly 
and to finally reset itself, thus bringing the F, S, 
and T scan points back to the reset state. The 
possibliity of fault or error detection is provided 
for the controller and the ferreed coils, but is not 
provided for the ferreed switch. 


Page 10 


4.38 The SD includes the controller, the matrix, 
and the magnetic latching relays. The 
controller receives, decodes, and administers orders 
received from the CC or the signal processor. The 
matrix consists of wire-spring relays through which 
a pulsing path may be set up to operate or to 
release a desired magnetic latching relay. The 
relays make up the signal distribution paths. 


4.39 Malfunctions of the controller, the matrix, 

or the selected magnetic latching relay are 
indicated by the inability of the controller to cycle 
completely and to return to the reset state as 
checked by the F, S, and T scan points. 


TELETYPEWRITER MAINTENANCE 


4.40 The teletypewriter (TTY) maintenance 

program (PD-1A029) is a diagnostic program 
(TTDN) that isolates a fault within a given TTY 
circuit to a small number of replaceable circuit 
packages within the transmit-receive unit or to 
the TTY loop. The TTY itself is not diagnosed 
but the absence of current which takes the form 
of an open loop is noted. The program performs 
a series of exercises on the TTY circuit, collects 
the results of the exercises, compares them with 
expected results, and reports the results of the 
comparison to maintenance personnel via the 
maintenance TTY. 


AUTOMATIC MESSAGE ACCOUNTING MAINTENANCE 


4.41 The automatic message accounting (AMA) 

maintenance programs (PD-1A030) consist 
of the AMA-fault recognition (AMA-FOR) program 
and the AMA diagnostic program. The AMA-FOR 
program is entered via the AMA output programs 
whenever a condition is detected which makes the 
recording of call data impossible or of questionable 
accuracy. The primary purpose of the AMA-FOR 
program is to determine whether or not the trouble 
has permanently affected unit operation. It is 
possible that the detected condition was merely a 
transient error and that the unit can continue to 
be used for recording data output. If the trouble 
is of a more permanent nature, it is necessary to 
place the standby AMA into service to restore 
normal operation. 


4.42. The AMA-FOR program is started when 
any of the following conditions occur during 
the data output program. 
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(a) A not-all-zero condition is encountered upon 
interrogation of the AMA master scanner 
points prior to transferring a block of data. 


(b) A positive signal exists on an alarm output 

lead (read every 5 milliseconds during data 
transfer) indicating that at least one of the master 
scanner points has gone high. 


(c) Two consecutive tape reading errors occur 
during a data transfer check sequence. 


4.43 The AMA-FOR program consists of the 
following major parts: 


(a) Master scanner point check sequence 


(b 


= 


Tape bypass operation in maintenance mode 
No. 1 


(c) Normal mode recording and check sequence. 


5. MAINTENANCE CONTROL PROGRAM 


5.01 The purpose of the MAC program is to 

control and to administer various deferrable 
maintenance programs specified in the MACR. These 
maintenance programs include diagnostic, audit, 
routine exercise, and deferrable fault recognition 
programs. The specified maintenance program is 
called the client program. The MAC program 
administers operation of the client program and 
interleaves segments of the client program with 
the processing of calls (Fig. 3). Control is returned 
to the call processing programs after each segment 
of the client program so that telephone service is 
not interrupted. Some of the tasks carried out by 
the MAC program are as follows. 


(a) Answers diagnostic requests usually from 

an FOR program recorded in the subsystem 
status table. These diagnosite requests are 
handled on a priority basis. For example, units 
such as CCs and PSs have the highest priority. 


(b) Answers routine exercise requests in the 

recorded routine request table. Four priority 
levels are available: level A, the highest, is 
for requests made via the maintenance TTY; 
level B is for requests made by programs; and 
levels C and D are for requests made by automatic 
scheduled routine exercises. 
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(c) Initiates certain trouble alarm scans periodically 

which perform trouble detection functions. 
For example, the single-error counter in the CC 
is scanned periodically. An excessive error 
count initiates an error-evaluation program which 
leads to a diagnostic program. 


(d) Ensures that no client program holds the 
MACR for more than 10 minutes. 


(e) Handles the communication of all client 
programs with the maintenance TTY channels. 


(f) Performs the following tasks that are common 
to many of the maintenance programs: 


e Timing 


© Maintenance bookkeeping, such as updating 
system status and recording error information 


® Control of common maintenance facilities, 
such as the audible and the visual alarms 
and the monitor bus. 


(g) Administers repeated tests. 


5.02 The MAC program (PD-1A005) is entered 

from the main program as the lowest priority 
job (level E). The time between any two consecutive 
MAC programs varies with traffic conditions. The 
MAC program starts the client program in the 
MACR. The client program carries out a segment 
of work which has a maximum duration of 10 
milliseconds excluding interrupts. Upon completion 
of the work segment, the client program relinquishes 
control to the main program. Fig. 8 shows the 
interleaving of deferrable jobs (base level) for call 
processing and for maintenance with 5-millisecond 
interrupt input-output jobs (level J). 


5.03 The MAC program determines whether the 

MACR is busy. The register is busy when 
it is assigned to any client program. If the register 
is idle, the MAC program searches for diagnostic 
requests and then for routine exercise requests. 
If a request is found, the appropriate client program 
is initiated and the MACR is assigned to this 
program. If no requests are found, some very 
low priority jobs (such as diagnostics) are performed. 
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Fig. 3—Interleaving of Maintenance and Call Processing Jobs 


6. MAINTENANCE CONTROL REGISTER 


6.01 The MACR is a memory area in the CS used 

primarily by the deferrable programs. The 
MAC program administers, coordinates, and schedules 
this register. The maintenance program specified 
by the MACR is called the client program. 


6.02 The MACR consists of a group of about 500 

CS words which are used for administering 
the maintenance programs and for recording the 
results obtained. The MACR is made up of two 
parts. The first part is the work area which is a 
private memory area for a client program while it 
is in control of the register. The second part is 
the long-term record area which provides the client 
program with reference data pertaining to the 
subsystems. 


6.03 The work area is used by a client program 

to record the results of the various tests 
that the program performs. Also the work area 
contains administrative information, such as the 
identity of the unit under test and of the type of 
program being carried out. 


6.04 The long-term record area consists of the 
following tables. 


(a) Routine Request Table: This table is a 
waiting list for routine exercise programs, 
TTY messages (inputs), etc. 


(b) General Buffer Table: This table is used 

by maintenance programs for passing 
information on to other maintenance programs 
which will be used at a later time. For example, 
the table is used when a FOR program finds a 
fault condition and requests subsequent diagnostic 
action. While determining that the malfunction 
is a fault and is not an error, the FOR program 
uncovers some information that would be helpful 
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to the diagnostic program. This information is 
entered into the general buffer area. 


(c) Error Record Table: This table is used 
by an FOR program for recording error 
data, such as the pattern of units in operation 
at the time an error is detected. Also this table 
contains an error counter for certain subsystems. 
An error counter is incremented when the FOR 
program associated with the unit under test 
determines that an error has occurred. Error 
counters are examined periodically, and appropriate 
action is taken if a high-error count is found. 


(d) Subsystem Status Table: This table is a 

history file on the various subsystems. The 
table records whether the status of each subsystem 
for the major processing units (CC, CS, PS, and 
CPD) is active, standby and ready to be active, 
standby and out of service, or standby and 
requesting diagnostic action. 


(e) Miscellaneous Record Table: This table 

contains specialized information for the various 
maintenance programs. Memory spaces in this 
table are permanently assigned to a client 
program for use in recording private administrative 
records. 


7. DIAGNOSTIC PROGRAMS 


7.01 Diagnostic programs localize a fault to a 

small number of plug-in circuit packs within 
a system unit that has failed diagnosis and that 
has been taken out of service. A diagnostic 
program carries out a fixed sequence of tests that 
are performed by monitoring either the normal 
outputs of a unit or the test points located within 
the unit. The test points are monitored by a 
scanner during a control read operation. The 
scanner examines information either directly or via 
a diagnostic bus. 
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7.02 A diagnostic program records in the MACR 

whether each test passes or fails. From 
these test results, the number generation program 
determines the trouble number which is printed 
out by the maintenance TTY. Maintenance personnel 
can request a raw data printout via the maintenance 
TTY. This is a direct printing of the pass or the 
fail results of each diagnostic test. 


7.03 Diagnostic programs are relatively low priority 

maintenance tasks. These programs are 
requested by a FOR program that has detected a 
fault or by an unusually high error rate. The 
diagnostic programs are generally long and require 
a substantial amount of CS memory for recording 
tests results. The MACR, under control of the 
MAC program, serves as a temporary memory for 
each. diagnostic program. 


TROUBLE LOCATING NUMBER PRODUCTION 


7.04 At fixed points in each test program, the 

stored test results are sent to a number 
generation routine. A number of operations are 
performed on the test results so that new numbers 
are generated. At the completion of testing, a 
number reduction routine performs further operations 
on the previously generated numbers and then 
combines them into a 23-bit trouble locating number. 
If the circuits involved in the test respond as 
expected during the entire test procedure, the 
trouble locating number is the all-tests-passed 
number that is stored in memory and is applicable 
to that test. This number is stored in memory 
for each circuit that has a diagnostic program. 
After the tests are completed, a comparison is 
made between the generated number and the 
all-tests-passed number. A mismatch indicates a 
test failure or failures requiring a TTY message. 
This message includes the generated trouble locating 
number to be looked up in the trouble locating 
manual which, in turn, indicates the particular fault 
encountered in the test. 


8. ROUTINE EXERCISE PROGRAMS 


8.01 There are two types of routine exercise 

programs: scheduled automatic routine 
exercise programs and demand routine exercise 
programs. 
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SCHEDULED AUTOMATIC ROUTINE EXERCISE PROGRAMS 


8.02 The automatic routine exercise programs 

have periodic schedules. There are three 
automatic program classes which are determined 
by the scheduling technique. 


8.03 Class I programs are rigorously scheduled 

at a relatively high frequency. These 
programs are entered from the high-priority main 
program regardless of the office traffic. They 
must of necessity be fairly short, since they are 
performed even during the busy hour. An example 
of a program assigned to this class is that program 
which interrogates and resets the store error 
counters. This must be done on a strict schedule 
to ensure meaningful interpretation of the contents 
of the counters. 


8.04 Class Il programs are also rigorously 

scheduled, but at a much lower frequency. 
Programs which must be performed every hour, 
or at some specific time during the day, are assigned 
to this class. An example is a program to request 
routine exercise of matchers. 


8.05 Class III programs are the lowest priority 

programs in the system. These exercises 
are performed in system spare time when no other 
jobs are waiting. These exercises are ordered in 
a circular list, so that when one is completed, the 
next one in the list is initiated. Most of the routine 
exercises are assigned to this class. An example 
is programs to verify and update status words in 
temporary memory to insure that they agree with 
the actual system status. 


DEMAND ROUTINE EXERCISE PROGRAMS 
8.06 The demand routine exercise programs are 
initiated upon request. The request can be 
initiated by the TTY or by some other program. 
All automatic programs can be requested as demand 
programs. Some examples of demand programs 
are 
(a) A program to remove a unit from service, 
(b) A program to restore a unit to service, 


(c) A program to print out the status of a 
particular unit, 
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(d) A program to print out the contents of a 
specified call store location, etc, and 


(e) Programs that audit the network memory. 


8.07  Allof the maintenance programs are normally 

executed by the active CC or by both the 
active and standby systems. Demand routine 
exercise programs are provided to allow the execution 
of almost all of these programs on a repeated basis 
by the standby system. The need for this ability 
may arise if a marginal trouble develops which is 
not detected by the diagnostic programs. To run 
the standby CC independently of the active CC 
(that is, off-line), all that is required is to interconnect 
the CCs, CSs, and PSs so that the CCs operate 
as two independent systems. 


8.08 If it is desired to execute some program 

continuously, starting at address A and 
ending at address B, this could be accomplished in 
the following manner. An input message would 
request that the standby system execute the 
program from address A to address B. This 
demand exercise would modify CS and PS 
configurations to set up two independent systems. 
The active CC would stop the standby. CC and 
control write the start address A into the standby 
program address register. It would then set up 
the breakpoint match mode to monitor address B 
with the interrupt and stop standby options specified. 
Next, it would start the standby CC and return 
to call processing. The standby system would then 
begin executing the program at address A while 
the active system ran its normal call programs. 
When the standby system reached address B, the 
active matchers would be alerted, stop the standby 
system, and interrupt the active system with a 
G-level interrupt. This interrupt program could 
restart the standby system at A and return to 
call processing, etc. 


9. TRUNK AND SERVICE CIRCUIT TEST PROGRAMS 
FUNCTION 


9.01 A request for trunk and service circuit 


automatic testing may be originated directly . 


or indirectly. Direct requests are from the 
maintenance TTY, from the trunk and line test 
panel, or from the main program timing. Indirect 
requests result in the setting of a request flag in 
the MACR which honors the request when higher 
priority maintenance work has been completed. The 
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administration program performs the actions required 
to prepare a circuit for testing. Control is then 
passed to the diagnostic program for that particular 
type of circuit. For test program purposes, any 
circuit that has an assigned trunk network number 
and that is connected to the trunk link network is 
treated as a trunk circuit. 


9.02 A diagnosis requires a network connection 

between the circuit to be tested and the 
one or more test circuits. The connected test 
circuits are set to their various states, and scans 
are made to check the responses of the circuit 
being tested. Upon completion of testing, the test 
results indicate whether a diagnosis passed or failed. 


9.03 The administration program disposes of the 

tested circuit by returning it to an idle list, 
by putting it on the trunk maintenance request 
list, or by putting it on the trunk out-of-service 
list depending upon the results of the test and 
upon certain system conditions. A TTY message 
is given for all failures and, in some cases, for all 
tests that passed. 


AUTOMATIC PROGRESSION TESTING 


9.04 The automatic progression testing program 

is entered from the main program on a 
scheduled basis. Each time the automatic progression 
test program is entered, the trunk maintenance 
request list (TMRL) is examined for trunks that 
have remained on the list sinee the previous entry 
to this program. All such trunks are removed from 
the TMRL and are identified by a TTY message 
(TNO1, TN02, TNO3, or TN04). The program 
continues with an entry to the trunk network 
maintenance subroutine which selects trunks for 
testing when they appear on the TMRL. When 
the TMRL tests are completed, trunk automatic 
progression testing begins. Trunks are selected 
numerically in the order of their trunk network 
numbers. The selection process generally includes 
idle, busy, and unassigned trunks. 


9.05 The trunk network diagnostic subroutine is 

entered with the selected trunk, and the 
trunk is prepared for testing if it is idle. Control 
is then passed to the particular diagnostic program 
responsible for the circuit actions needed to test 
the selected trunk. A trunk that passes the test 
is restored to the idle list, while a trunk that fails 
the test is entered on the TMRL. Before another 
trunk is selected for diagnosis, control is transferred 
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to an MACR so that higher priority maintenance 
work can be done before returning to this program. 


9.06 Trunks that are service busy, out of service, 

or unassigned are passed by when automatic 
progression testing is being done; however, each 
time an out-of-service trunk is found, its trunk 
network number is printed. 


TESTING TRUNKS APPEARING ON LISTS 


9.07 The TMRL is a fixed length list that contains 

information for five trunks. When a trunk 
is to be entered on it, the first available space is 
used. Upon each entry of the trunk network 
maintenance subroutine, the entry appearing 
uppermost in the TMRL is placed at the bottom 
and all other entries are rotated toward the top. 
The trunk network number occupying the bottom 
position is given to-the trunk network diagnostic 
subroutine for testing. A variety of programs may 
request a diagnosis of a trunk by entering appropriate 
information on the TMRL or (2-wire ESS only) on 
the auxiliary trunk maintenance list (TMLA). 
Periodically or interleaved with automatic progression 
testing, one of the trunks on the TMRL or the 
TMLA is selected for testing when an entry is 
made to a trunk network maintenance subroutine. 
The selected trunk is prepared for testing by the 
trunk network diagnostic subroutine and is tested 
by the diagnostic program. 


9.08 Test results are returned to the trunk 
network maintenance subroutine. A trunk 


that was not tested is marked maintenance busy | 


and is left on the TMRL for subsequent retrials 
or for disposition as specified by automatic progression 
testing. Trunks that pass the test are idled, while 
those that fail the test are entered on the 
out-of-service list if possible. 


9.09 Only 15 trunks can be taken out of service 
by automatic trunk maintenance between 
trunk network program entries. The number of 
trunks that may be taken out of service in a 
particular trunk group is also limited as follows: 


© One trunk in groups containing one through 
four trunks 


© Two trunks in groups containing five through 
eight trunks 
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e@Three trunks in groups containing nine 
through twelve trunks 


@ Four trunks in all larger groups. 


When a limit is reached, additional failing trunks 
are returned to service. 


9.10 Test results are given by a TTY message 
after each test whether it passed or failed, 
and the trunk is removed from the TMRL. 


9.11 In the 2-wire ESS when the trunks specified 

in the TMRL have been tested, trunks 
specified by the TMLA are idled in memory and 
in hardware. The list of trunks in the TMLA is 
shifted to the TMRL if vacancies occur and if the 
TMLA contains fewer than five trunks. If both 
of these conditions are not met, trunks from the 
TMLA are restored to service until the conditions 
are met. In 4-wire ESS, trunks which are placed 
on the TMLA are not handled by the trunk and 
service circuit test programs. Instead they are 
idled in memory and in hardware by a program 
operating in level L independently of the MACR. 
When processing is completed, automatic progression 
testing is resumed if it had started; otherwise, 
control is returned to the MACR. 


TESTING TRUNK GROUPS 


9.12 On reception of a request for testing a 
trunk group, ‘&’ TTY output message is 
initiated to indicate that testing has started. In 
numerical sequence all trunk network numbers in 
the office are examined, and only those numbers 
belonging to the requested group are tested if they 
are idle. Test results (pass, found busy, or failure) 
are printed out by the TTY. When a diagnosis is 
blocked, a second attempt is made before the TTY 
is activated. Upon completion of testing, an 
end-of-test message is printed out by the TTY. 


9.13 Time breaks are taken during trunk group 
testing through interaction with the MACR. 


INTERACTION WITH MAINTENANCE CONTROL REGISTER 


9.14 Except for the functions performed on level 

J, the trunk maintenance jobs are relegated 
to a low-priority program level. Various time 
breaks are incorporated in the trunk maintenance 
program by returning control to the MACR each 
time a circuit has been tested or when 64 consecutive 
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circuits have been found busy or out-of-service. 
This ensures that higher priority maintenance work 
is given preference. 


PREPARATION OF CIRCUIT FOR TESTING 


9.15 The trunk network diagnostic subroutine is 

given the trunk network number of the 
selected trunk. The requesting program is notified 
that the test cannot be made if the trunk is busy, 
out-of-service, or unassigned. Trunks that appear 
idle in memory are blind idled. This procedure 
sends release orders to all SD and CPD points 
associated with the trunk. If an automatic diagnostic 
program exists for the selected circuit, that program 
is entered. If no diagnosis is available, the 
requesting program is informed of that condition. 
The trunk network diagnostic subroutine may be 
entered directly from the trunk and line test panel 
program when that unit requests a diagnosis for a 
particular trunk network number. 


CIRCUIT TESTS 


9.16 The test procedure for all circuits requires 

connection to related circuits, thus setting 
the circuits to their various states and checking 
their reaction by making scans on some or on all 
of the associated ferrods. Each individual test 
program proceeds with a fixed test pattern which, 
when good circuits are involved, returns a fixed 
pattern of test results. The test results are 
obtained by storing in memory all scan results 
and by storing an indication of the success or the 
failure of hardware actions (network operations, 
SD operations, etc). Testing is not suspended at 
the time a failure occurs, but only when the entire 
test procedure has been completed. 


9.17. When testing is initiated by the trunk and 

line test panel, it may request a printout 
of the raw data as it is received by the test 
program. This feature requires the operation of 
keys at the alarm, display, and control panel; 
otherwise, the results produce a trouble locating 
number. 


TEST CIRCUIT FAILURES 
9.18 When a trunk diagnosis fails, the trouble 


may be in the test circuit. The method 
used to detect test circuit troubles is as follows. 


Each test circuit has an associated memory bit: 


indicating whether the previous test passed or 
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failed. This memory bit is updated after each test. 
When two consecutive tests using the same test 
circuit have failed, the test circuit is entered on 
the TMRL. A diagnostic routine for the test circuit 
is requested as a result of TMRL processing, and 
the test circuit is connected at random to any 
available circuit of the type specified by the test 
program. This time a failure (the third consecutive 
failure using the test circuit) causes the test circuit 
to be entered on the trunk out-of-service list; 
therefore, subsequent tests requiring this test circuit 
are blocked. 


10. TRUNK ERROR ANALYSIS PROGRAM (2-WIRE 
ESS ONLY) 


10.01 Whenever the system encounters a trouble 

condition during call processing or routine 
trunk testing, it refers any trunk or service circuit 
involved in the action to the trunk and service 
circuit maintenance programs for diagnosis. The 
word trunk is used to include service circuits or 
trunk circuits with their transmission facilities. If 
the trunk circuit fails both the subsequent diagnostic 
test and the automatic retest, it is considered to 
have a detectable fault and the system attempts 
to remove it from service. On the other hand, if 
the trunk circuit passes a diagnostic test or if for 
some reason a diagnostic test is not completed, 
then an error is attributed to the circuit. The 
trunk error analysis program processes these errors. 


10.02 Trouble symptoms on trunks include network 

continuity check failures, SD failures, and 
failures on any other peripheral order bus action 
when type 1 or type 2 failure options are used. 
Other trouble symptoms include transmitter timeouts, 
internal circuit check failures, invalid trunk state 
conditions found by audits, receiver partial dials, 
permanent signals, etc. Also a trunk failure during 
an automatic progression test is considered a 
trouble symptom. 


10.03 After a trouble occurs, many suspected 

circuits will pass a subsequent diagnosis 
since many trouble symptoms are independent of 
the individual trunk circuit submitted for test. 
Each trunk circuit that passes a diagnostic test 
initiated by a trouble symptom is considered to 
have been in error. A statistical check is made 
to ensure that such a circuit is not performing 
marginally or that it does not have a fault which 
cannot be detected by the diagnosis. All other 
trouble symptoms which do not result in diagnostic 
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failures are also considered to be errors. Included 
are the cases where 


(a) A diagnostic test is not provided 
(b) A diagnostic test is blocked 


(c) A diagnostic test request is denied on the 
number of trunks already out of service or 
on the maintenance request list 


(d) A diagnostic test is skipped because a trouble 
condition is suspected in the connecting office 
(that is, transmitter timeouts). 


10.04 The processing of errors by the trunk error 

analysis program consists of a relatively 
simple comparison of the number of errors associated 
with a particular trunk to the number of errors 
occurring on other trunks in the same group. A 
maximum of 20 trunks can be analyzed simultaneously. 
Running counts are maintained on the number of 
errors occurring on each trunk under study and 
on other trunks in the group. If a sufficient 
number of errors occurs on other trunks of the 
group before a specified number occurs on the 
particular trunk, the trunk is considered to be 
normal. On the other hand, if the specified limit 
of errors on the particular trunk is reached first, 
the trunk is considered to have a high-error rate. 
It is understood in this determination that the 
trunk has been involved in a statistically improbable 
percentage of the total number of errors occurring 
in the group. 


10.05 The validity of this method of error analysis 

depends on the errors occurring on a group 
of normal (no fault) circuits that are distributed 
either randomly or uniformly over the group. In 
general, this is not the distribution case when the 
system has a fixed preference for selecting trunks 
of normal call usage. Unequal trunk usage implies 
unequal probability of errors for trunks in the same 
group. For this reason, error analysis is not applied 
to incoming trunks or to 2-way trunks. 


10.06 A high-error rate on a trunk implies either 

a marginal performance or a fault undetectable 
by a diagnostic program. When a trunk is found 
to have a high-error rate, the trunk error analysis 
program removes the trunk from service unless a 
maintenance limit is exceeded or unless, at the 
time the high-error condition is detected, the system 
has not completed abandoning a call involving the 
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trunk. When the system removes such a trunk 
from service, it initiates a repeat test of the circuit 
in an effort to trap a marginal condition. 


10.07 Because of the statistical check of trunk 
errors, the need for individual trunk error 
output messages is obviated. Once daily and upon 
request, this program prints the number of errors 
for various sources. Also counts are made of the 
disposition of errors treated by the trunk error 
analysis program. Although the system usually 
selects the trunks upon which error analysis operates, 
facility is also provided for manual selection. 


11. LINE INSULATION TESTS (2-WIRE ESS ONLY) 


11.01 The automatic line insulation testing (ALIT) 

program tests line insulation values. All 
idle lines, except ground-start PBX lines, are tested. 
The ALIT program may be started at a specified 
time of day by program control or by requests 
from either the local test desk or the maintenance 
TTY at the master control center. The following 
tests are performed. 


(a) Short Circuit and Ring. to Ground (SRG): 

This test is used to detect trouble in drop 
wire and inside wire at the subscriber’s premises 
(leaks between tip and ring) and in open wire 
conductors (leaks from ring to ground). It also 
checks for end point contactor closure. 


(b) Tip and Ring to Ground (TRG): This 

test checks for trouble in the cable terminals 
and the cable sheath (leaks from tip or ring to 
ground). 


(c) Foreign Potential on Tip or Ring (FEMF): 

This test is used to detect defects in 
underground and in overhead cable sheaths (leaks 
from tip or ring to battery). 


11.02 The sensitivity of the test circuit is variable 

depending upon the range specified and 
the cross-connections of the circuit. There are 
four test ranges available for each of the three 
sets of cross-connections. 


11.03 When a line insulation failure is detected, 

it is reported via the ALIT TTY. Since 
more than one office may have access to the same 
ALIT TTY, additional messages are typed at the 
start and the end of a test cycle to identify the 
type of test, range, and originating office. 
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12. AUDIT PROGRAMS 


12.01 Audit programs operate under control of 

the MAC program. The function of audit 
programs is to detect and to eliminate erroneous 
or inconsistent information in the CS memory. All 
of the audit programs are scheduled by the MAC 
program for routine execution throughout the day 
(usually on an hourly basis). Most of the audit 
programs can be requested via the TTY. Also the 
audit programs are requested by the MAC program 
when program indicators warn of possible trouble. 


12.02 To detect errors in the CS, audit programs 
use the following methods. 


(a) Compare redundant (distinct from duplicate) 

information. (Redundant information exists 
if it can be found in a number of different forms 
within the CS. Duplicate information exists 
when an exact copy of it is available in a PS 
or in a different CS.) 


(b) Determine whether portions of the information 
violate certain restrictions. 


(c) Compare information in the CS with associated 
backup information in the PSs. 


12.03 When the audit program detects either a 

restriction violation or a disagreement 
between redundant information, all equipment 
associated with the suspect CS memory location is 
made idle and is available for use when required. 
When a disagreement between the PS and the CS 
memory is detected, the audit program corrects 
the CS. Audit program results are printed out by 
the maintenance TTY of the master control center. 


12.04 The emergency action control program 

combines the individual audits into groups 
for use when the existence of trouble makes it 
necessary to check and/or to reconstruct the 
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information of certain CS areas or of an entire CS 
memory. The emergency action control program 
is nondeferrable and must be completed before 
call processing can be resumed. 


12.05 The audits are used in effecting the phases 

of system reinitialization (Section 231-113-301 
for 2-wire ESS or 231-413-301 for 4-wire ESS). The 
phases of system reinitialization can be used only 
if a working configuration of a CC, a PS, and a 
PS bus exists. In the event of severe trouble, a 
working configuration is established by emergency 
action circuits in the CC. 


12.06 All phases of reinitialization are called for 

by the program when certain trouble 
conditions are detected. The phases are performed 
in order starting with phase 1 and continuing until 
the trouble is corrected. Each phase performs a 
more extensive operation than the preceding phase. 
The maintenance attendant can use switches to 
select any phase of reinitialization. The phases 
should be selected in order. 


13. OFF-LINE MAINTENANCE PROGRAMS 


13.01 Off-line maintenance is performed when 
the CC, the PS, the PS bus, and in some 
cases the CS are separated from the rest of the 
system and are combined to repeatedly carry out 
selected programs. Off-line maintenance is used 
either to isolate marginal conditions that may be 
frequency-dependent or to isolate marginal troubles 
that may be configuration-dependent. For example, 
a high-error count may be experienced only when 
a particular CC bus and a PS are used together. 
The source of errors, in this case, cannot be isolated 
by normal methods because switching out any of 
the units involved causes the errors to stop. Off-line 
maintenance is initiated manually via the maintenance 
TTY. Appropriate tests can be performed repeatedly 
off-line until the source of trouble is identified. 
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D. CKL/CWL Logging into CIMAP/SSC via Status Reporter 


CKL/CWL information will be logged (added) in CIMAP/SSC from GOC, CIMAP/CC, GDS and 
OPS/INE. Since the logging and matching of CKLs/CWLs from GOC with CIMAP/CC, INE and GDS 
is complex, the details provided in this section are necessary to understand the process. The 
information that these systems provide to the Status Reporter is as follows. 


* GOC CKL/CWL Logging into CIMAP/SSC - GOC will transmit to CIMAP/SSC via the Status 
Reporter all CKI./CWL information currently logged in GOC for a particular order/item at issue 
time. This information could have been logged in GOC at order entry time, mechanically generated 
by CDA or manually added in GOC at circuit design time. Any additional CKLs/CWLs logged in 
GOC downstream will be sent to CIMAP/SSC. This CKL/CWL information for each location 
includes the following: 


— COMMON LANGUAGE® (CLLI) code. 


— CKL/CWL ID which is a 1-4 A/N code that untquely identifies a work location on a circuit. 
CKLs/CWLs can be logged with identical CLLI codes; it is the CKL/CWL ID that uniquely 
identifies the work location for reporting purposes. These codes are determined by methods 
established by each individual operating company. 


— GOC Indicator (optional) which is a one-character code for distinguishing between CKLs and 
CWLs on the circuit. The implementation of the CKL/CWL distinction for GOC was shipped in 
Release 14.1.2. The indicator codes and the critical reporting dates associated with the indicator 
values are as follows: 


IND CKL/CWL CRITICAL REPORTING DATES 


WwW CWL RID,DVA,WOT DD (IAD if applicable) 

K CKL RID,DVA,DD (IAD if applicable) 

L CKL LAM,RID,DD 

E CKL RID,DD 3 

) no distinction Any critical reporting date applicable to the CKL/CWL 


level and having objective date in GOC at the order 
level. 


For all indicators (W,K,L,E), PTD is a critical date but not a critical reporting date in GOC. 
This same information is available in CIMAP/SSC in the OPS GOC IND table. The critical 
reporting dates for each GOC indication are stored in this table (rather than hard-coded) so that 
operations can easily respond if GOC rules are changed. The table setting for tracked events will 
be shipped populated by Bellcore in accordance with current GOC criteria. 


CIMAP/SSC matcher gives the users the option of using the GOC Indicator to build intelligence 
into the matcher algorithm. The added intelligence will result in more accurate matching of 
GOC CKLs/CWLs with those from CIMAP/CC and GDS. The algorithm could be directed, for 
example, to match CIMAP/CC locations with GOC locations only if the GOC Indicator is "W" or 
to match GDS locations with GOC locations only if the GOC Indicator is "L". To use this 


COMMON LANGUAGE is a registered trademark and CLEI, CLLI, CLFI, and CLCI are trademarks of Bellcore. 
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intelligence, the BCC must implement the GOC Indicator (in the TIRKS System) to allow for 
CKL/CWL distinctions and not as a mechanism for selecting a particular critical reporting date 
stream for a location without regard to whether it is a CKL or CWL. The GOC Indicator 
information is stored in the OPS GOC IND TTS table in CIMAP/SSC. See Appendix D of the 
CIMAP/SSC User Manual, BR 190-582-305, for details. 


— The objective dates at the CKL/CWL level for the events are the dates logged in GOC and sent 
to CIMAP at the order/level. If an objective date was not received from GOC for a particular 
event, the objective date field will be blank for that event. 


— CIMAP/SSC will then set the GOC Tracking Flag to "yes" or "no" depending on whether the 
event for a particular CKL/CWL is a critical reporting date at the level in GOC. This will be 
determined by using a combination of the following: 


— The value of the Tracked Events flags (e.g., DVA-T, DD-T) in the OPS GOC IND table. 


— Whether the objective date for the event was received from GOC at the order/item level and 
was entered in the OSSIC table in CIMAP/SSC. 


CIMAP/CC CWL Logging into CIMAP/SSC - At issue time or at order log time (for disconnects), 
CIMAP/CC will send to CIMAP/SSC via the Status Reporter all the CWL information generated by 
CIMAP/DOC and CIMAP/CC in determining what work has to be done at which work locations on 
the given circuit. The CC ADMIN CODE tables in provisioning and the STEP tables in CIMAP/CC 
are used to perform translations that result in work requests being built at CWI locations that 
match GOC. Additions/changes in CWL information downstream, as a result of a reissue, for 
example, will also be passed to CIMAP/SSC. The information for each CWL location includes the 
following: 


— COMMON LANGUAGE (CLLI) code. CIMAP/CC will never send more than one CWL for the 
same location. 


— CWL DD of "blank". The importance to the matching process will be discussed in the section on 
CKL/CWL Matching. 


— Objective dates for each event. These dates will be the GOC objective dates, CIMAP/CC 
calculated dates based on table entries if GOC dates are not provided, or “blank” if neither date 
exists. 


— Tracking Flag for each event of "yes" or "no". This flag indicates whether CIMAP/CC will be 
posting completions of the CWL event. 


CIMAP/CC sends CIMAP/SSC CWL information for any order (e.g., message, special,....) that 
CIMAP/CC is working. CIMAP/SSC will store the information in the IA database. The Status 
Reporter will notify GOC of any CWL completions/jeopardies posted from CIMAP/CC. 


GDS CKL Logging into CIMAP/SSC - When GDS receives order information from the TIRKS 
System, it will send to CIMAP/SSC via the Status Reporter all CKL information generated by GDS 
in the process of determining what outside work is to be done at which work locations on a given 
circuit. Additions/changes to this information downstream will also be passed to CIMAP/SSC. The 
information for each CKL location includes: ~ 


— COMMON LANGUAGE (CLLI) code. GDS may pass two CKLs with identical CLLI codes. 


— END LOC code of "A", "Z", or "D". For CIMAP/SSC to uniquely identify two GDS CKLs with 
the same CLLI code, GDS will indicate whether the work at the CLLI code is at the "A" end, "Z" 
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end or "D" disconnect end of the circuit. 


— CKL D as populated on the LOOP2 format. This same CKL ID will be logged either manually 
or mechanically in GOC. 


— Objective dates for each event if they exist in GDS, otherwise “blank”. 


— Tracking Flag for each event of either “yes”, or "no". This flag indicates whether GDS will be 
posting a completion of the CKL event. 


GDS sends CIMAP/SSC CKL information for any order issued from the TIRKS System that GDS is 
working. CIMAP/SSC will store information in the IA database. The Status Reporter will, however, 
notify GOC of any item level or CKL level completions/jeopardies posted by GDS. 


e OPS/INE CWL Logging into CIMAP/SSC - At issue time OPS/INE will send to CIMAP/SSC via the 
Status Reporter the OPS/INE locations involving Intelligent Network Transmission Elements that 
are being worked by INE. 


The information for each INE location includes: 


— COMMON LANGUAGE (CLLI) code. An eleven-character code with the ninth character a "K" 
followed by a frame number. The code will be unique to OPS/INE. 


— CWL ID of "blank". 
-— Objective dates for each event. 


— Tracking Flag for each event of "yes" or "no". This flag indicates which critical report date 
OPS/INE will be posting. The date (e.g., DVA, WOT, DD) is selected by the user in the INE 
AUTO RELEASE (TTS) table in OPS/INE. OPS/INE posts only one critical date. The 
CIMAP/CC users should coordinate with the OPS/INE system administrator if CIMAP/CC has 
critical date dependencies involving INE locations in the CC STEP tables. 
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E. CKL/CWL Matching 


The matcher algorithm in CIMAP is responsible for matching OPS CKLs/CWLs with GOC 
CKLs/CWLs. This task is complicated for the following reasons: 


e GOC and OPS CKLs/CWLs are generated by separate processes and at different times. In most 
companies, CKLs/CWLs are manually logged into GOC either at order log time or at circuit design 
time. CDA can also be used to mechanically log CWLs in GOC at design time. CIMAP/CC uses 
information from the WORD document and translation tables to generate CKLs/CWLs that match 
those logged in GOC when CIMAP/CC posts jeopardies and completions. GDS builds work at 
locations passed by CIMAP/DOC. 


GOC CKLs/CWLs carry an ID which uniquely identifies work locations in GOC. No foolproof 
mechanism currently exists in Operations for generating CKL/CWL IDs that would correctly match 
those in GOC. The result is that one or more Operations centers may be completing work back to 
GOC using identical CLLI codes. For example, a circuit could have both inside CO work controlled 
by CIMAP/CC at the same CLLI code location that also has the outside plant work. The matcher 
may have to make a choice for completion purposes about which CIMAP/CC locations match which 
GOC locations without the benefit of the CKL/CWL ID. However, GDS is passed the CKL ID as 
populated on the LOOP? screen. If entered manually, this field should be populated with the same 
CKL ID as appears in GOC. If the SOAC/TIRKS Interface is available, SOAC will populate both 
the CKL ID in the GOC and PREP databases with the same value. 


F. GOC-CIMAP/CC CWL Matching ws 


To make the most accurate choice of CKL/CWL matches, given these difficulties, the following 
matching rules and assumptions are used by the matcher. See Table 3-4 for examples. 


e If no additional intelligence is built into the matching algorithm using the OPS SUB field in the OPS 
GOC IND table or the CMULTLOC field in the SSC-OPTION table, the following rules are used by 
the CIMAP/SSC Matcher. See Example 1 in Table 3-4. 


— If GOC logs one CKL/CWL with a CLLI code that matches one CWL CLLI code logged by 
CIMAP/CC, they will be matched by the algorithm. This is a unique match since no other 
matching choices exist. 


— If GOC logs more than one CKL/CWL with the same CLLI code (but different CWL IDs) that 
matches one CWL CLLI code logged by CIMAP/CC, the algorithm will match the CIMAP/CC 
CWL with the first GOC CWL with the same CLLI code regadless of the CWL ID. The matcher 2 
assumes that CIMAP/CC will never send more than one CWL for the same location. This is a 
non-unique match since other matching choices exist. The user has the option to change the 
system generated match using commands on OSSCWL. 


e If the OPS SUB field is set to "C" for a particular GOC IND value (e.g. W), then the following rule 
applies as in Example 2. 


— The GOC Indicator field with valid values of W,K,L,E, or ) was added in GOC as of Release 
14.1.2. The GOC Indicator is used to distinguish between CKLs and CWLs and determines the 
critical reporting dates for the CKIL/CWL locations. CIMAP/SSC has an OPS GOC IND table 
which sets critical reporting dates for each GOC Indicator value. The tracked event flag fields in 
this table are shipped populated by Bellcore in accordance with current GOC criteria. This table 
contains an additional field, OPS SUB. For each value of the GOC Indicator, the user can 
specify the OPS subsystem that can match a CKL/CWL location with that indicator, For 
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example, if the OPS SUB field is set to "C" (for CIMAP/CC) for the GOC Indicator of "W", then 
a GOC CWL location with a GOC Indicator value of "W" can only be matched with a 
CIMAP/CC CWL. 


e If the CMULTLOC field is set to "Y" in the SSC-OPTIONS table, then the following rule applies. 
See Example 3. 


— If GOC logs more than ohe CKL/CWL with the same CLLI code that matches one CWL CLLI 
code logged by CIMAP/CC, then the one CIMAP/CC CWL is matched with all the GOC 
CKLs/CWLs with the same CLLI code regardless of the CWL ID. 


G. GOC-GDS CKL Matching 


GDS is passed the CKL ID from the LOOP2 screen by CIMAP/DOC. GDS software requires that this 
field be populated before the CKLs are passed to the Status Reporter. This CKL ID will be guaranteed 
to match the CKL ID in GOC if: 


e A company uses LOOP2 without the SOAC Interface but methods require that the same CKL ID be 
used in GOC and LOOP2 formats. 


e The TIRKS/SOAC Interface is available. SOAC will log the CKL ID in both GOC and the LOOP2 


screen. 


When the matcher receives GDS CKLs with CKL IDs, the GDS CKLs will be matched with the GOC 
CKLs with the same CKL ID. This matching rule takes precedence over all other matching rules. See 
Example 4 in Table 3-4. The OPS SUB field in the OPS GOC IND table is available to CIMAP/CC to 
build added intelligence into the matching algorithm since the CWI ID is not available to CIMAP/CC. 
With the CWL ID being required by GDS, the added intelligence is not needed by GDS. 


H. GOC-OPS/INE Matching 


The OPS/INE locations can be logged into GOC either manually after the CPC designs the circuit or 
mechanically by the Circuit Distribution Analysis (CDA) module in the TIRKS System. The logging 
must be coordinated in either instance to ensure that the eleven-character CLLI code location logged in 
GOC is the same as OPS/INE is sending to the Status Report. This will guarantee a unique match 
between INE locations and GOC CWLs. No Operations system other than OPS/INE should attempt to 
post the same eleven-character location. Example 4 shows this unique match of the OPS/INE location 
with GOC. The BCC user could choose not to track OPS/INE locations in GOC; however, operations 
will track the INE locations. 
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Table 3-4. GOC-CKL/CWL Matching Examples 
1. Matching without additional intelligence built-in via table entries. 


e OPS SRC = "blank" in OPS GOC IND table for GOC IND of ’blank’ means match any OPS 
CWL. 
e CMULTLOC = "N” in SSC-OPTION table. 


The algorithm matches the CIMAP/CC CWL with the first GOC CWL with the same CLLI code. 


GOoc 
ID CLLI CIMAP/CC 
CWLI ALBONMSM. sssicisssssscssscejiceeaticasasastatassassocnasessseseczsaasevzesonocas ALBQNMSM (unique match) 
CKL2 ALBONMMA. succcceccssesesssiiccasseavscnosrcssanesnnsussansnsnetenencancrsenense ALBQNMMA 
CWL3 ALBQNMMA 
CWI 4 ALBONMNGO | os iscsastectscessssssavssescsises ttesetvaasieastnonaiaseiecsegsovayns ALBQNMNO 


CWL5 ALBQNMNO 


2. The same matching with the following setting in OPS GOC IND table. 
GOC IND OPS SCR 


Ww C (match with CIMAP/CC CWL) 

K,L D (match with GDS CKL) 

E 

GOCc 

ID CLLI IND CIMAP/CC 
CWEE AL BONMSM  W asccscssccccsssstsiscccccssssasscscssssavessscctescasanassevissodeatssorsevecevensdeneeaens ALBQNMSM 
CKL2 ALBQNMMA L 
CWL3 = ALBQNMMA W ou... csccecssessseessesssteessecsssessesssseeseessneeseasseessecsnecssensnecsseessees ALBQNMMA 
CWL4 ALBQONMNO Wu ccccscsssssssesessessssssssssssssesssccssssssssssssserseseeseecsssssseeseaesness ALBQNMNO 
CWL5 ALBQNMNO W i 


3. The same matching with the addition of CMULTLOC = "Y" 


GOoc 
ID CLLI IND CIMAP/CC 
GWE. © ALDBONMSM ) Wooricsiscteccicaes ces ale seca aneu bipaans sree teees eset tien tesess ALBQNMSM 
CKL2 ALBQNMMA L 
GWL3 sALBQNMMA: Woes ck ceira ascents arian noidiadis en bhiahanens ALBQNMMA 
GWL4:  <ALBONMNO | (Wo jec2ssoscsicet ieee ser ENE eeiene ch Nees te aca asthe does ates eetsete 
CWL5: _ ALBONMNO! Wereisicsts acncin asssiisersenenteinietett gig reise Bbeseeastereees ALBQNMNO 


PROPRIETARY — BELLCORE AND AUTHORIZED CLIENTS ONLY 
See proprietary restrictions on title page. 


Generic Dispatch System Release 3.1 User Manual — Part 2 


4. 


BR 190-539-311 
Issue 6, August 1989, GDSR 3.1 


The matching algorithm will always match the GOC GDS CKL locations with the same 
CKL ID regardless of the CWLs logged by CIMAP/CC. INE locations should be unique. 





GOc 
ID CLLI CIMAP/CC GDS INE 
CWL1 ALBQNMSM.............0 ALBQNMSM 
CKL2 CKL2 ALBQNMMA 
CWL3 
CWL4 ALBQNMMAK01 10... ccc ccsceescsssnsscsneeassesseseseesseenseasseeseeeeneseenenenes ALBQNMMAKO1 
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I. Information Flow between GOC and the CIMAP Status Reporter 


As previously stated, order information is sent to CIMAP/SSC, GDS, OPS/INE and CIMAP/CC by as 
either CIMAP/DOC or EDIIS. These modules also notify GOC that a particular order has been sent to 
Operations. GOC will then notify the CIMAP Status Reporter of any updates or postings on that order 

in GOC, and the Status Reporter will inform CIMAP/SSC, CIMAP/CC, GDS and INE, as appropriate. 

In turn, the Status Reporter will notify GOC of all Post/Complete functions on the order, performed in 
Operations (See Figure 3-5). 


The information passed between GOC and the Status Reporter is as follows: 


Table 3-5. Information Passed between Status Reporter and GOC 





GOC TO STATUS REPORTER STATUS REPORTER TO GOC 
» ADDS » DATE COMPLETIONS 
— CKLs/CWLs 


e JEOPARDY POSTING 
e SUPPs/UPDATES 


— CANCELS e JEOPARDY REMOVAL 
— DATE RESCHEDULES 
— CHANGES IN OTHER DATA e MISSED FUNCTION CODES 
« DATE COMPLETIONS e AT DD COMPLETION, GCNOTE 
IS UPDATED USING COMMENTS 
e JEOPARDY POSTING/REMOVAL ON OSSOI. 


e IAD DATES FOR DISCONNECTS 
AFTER DD COMPLETION. 
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BETWEEN OPERATIONS & GOC 
VIA TCM AFTER ISSUE 
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Figure 3-5. Information Flow Between CIMAP & GOC via TCM 
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J. Critical Date Handling 


The following critical dates can be received from the GOC: DVA, WOT, FCD, PTD, DD, IAD, SWC, 
CTA (not displayed on OSSOT) and ASD. 


e The Order Information format (OSSOI) is a variable format that displays the critical dates 
appropriate for each order class-message, carrier and special. The Installation Configuration tables 
(OSSIC) can be set up to calculate objective dates for any event as offsets of other critical dates. 
However, if the actual objective dates are received from GOC, they will supersede the calculated 
dates. Prior to screening being completed, additional GOC objective dates can be added to an 
order/item in the IA database. After screening, additional GOC objective dates can be accepted 
only if a calculated date, based on an OSSIC offset or a CIMAP/CC calculated offset, exists in 
CIMAP for the event. For DOP orders, IAD and optionally DVA are scheduled in GOC at DD 
completion. If CIMAP is to receive these dates from GOC, calculated dates must exist in CIMAP for 
IAD and DVA based on an offset of DD. 


NOTE - If the user wants GOC critical date 
information on dates not tracked by SSC (e.g., 
WOT), that date must be in OSSIC with a 
tracking flag of "N". This includes postings 
back to GOC at the CKL/CWL level. 


CIMAP/CC receives all critical dates from GOC via CIMAP/DOC and displays them on the Cross 
Reference (CCXREF) format. CIMAP/CC posts only to GOC the Report Dates that appear in the 
REPORT field in the STEP tables. If a date is used in the STEP table but was not received from 
GOC, that date is calculated based on an interval designated in the CC REPORT DATE Table. 


GDS receives all critical dates from GOC via CIMAP/DOC and displays them on the Installation 
Special Work Request (GDISWR) format. GDS posts DD and optionally DVA back to GOC via the 
Status Reporter. 


The posting of jeopardies, jeopardy removals and critical report date completions (POST RID) will be 
sent from GOC to Operations or Operations to GOC depending on which system did the posting. If the 
posting fails in the other system, the Operations Error Handlers will inform the user if action is to be 
taken. This is discussed in detail in the section on Error Handling. GOC will also notify the Status 
Reporter of any reschedules of critical dates. When ttem level DD is completed, the Status Reporter will 
send the comment field on OSSOI to GOC as an update to GCNOTE in GOC. 


K. Disconnect Processing 
GOC supports two types of disconnect processing: regular and DOP for short. interval disconnects. 
e For regular disconnect processing, GOC supports the following: 
— IAD date entry by the user when the disconnect. order is logged. 


— Or GOC will generate the IAD date for all order/items when DD is completed on the last 
disconnect item on the order. The IAD date is calculated based on an offset interval from DD; 
the interval is defined in the GCINTU table. 


— GOC also has an IAD COMPL FLAG in the OPTION FLAGS table in provisioning. If set to 
"N", there is no IAD Processing. If "M", there is LAD processing with manual completion of IAD. 
If "A", there is LAD processing with GOC auto-completing IAD. The auto-completion of IAD is 
done via a nightly BMP run. If the option that uses a batch run to complete JAD is selected, the 
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GOC Interface will inform the Status Reporter of the completion. 


— If there is IAD processing and DD is completed, the order status goes from P to PX. When IAD is 
completed, the status becomes IX. If there is no IAD processing, the order status goes from P to 
IX on DD completion. 


e For DOP processing, GOC also supports the following: 
— ADOP field on the order “entry screen set to "Y" indicating a DOP order. 


— The order can not be logged with a RID date or any dates post RID except for DD. When the 
first DD (even a CWL DD) is completed on the order/item, the order status goes from P to PX 
and GOC schedules IAD, RID (optional) and DVA (optional). However, as of TIRKS Release 
15.0, IAD, RID and DVA will not be scheduled until DD is completed on the last item on the 
order, similar to regular IAD disconnect processing. These dates are calculated using the same 
GCINTU table, this time for DOP orders. This rule will be changed in a future TIRKS System 
release to parallel regular disconnect processing. 


— When IAD is completed, the order status becomes IX. 


e The following action is taken in CIMAP/SSC to handle the two types of disconnect processing in the 
TIRKS System: 


— First, it is strongly recommended that 


a. IAD tracking in CIMAP reflect GOC tracking of IAD in the TIRKS System so that the 
order status in both systems remains in sync. 


b. If IAD processing is used, the offset used to calculate IAD (and optionally DVA) from DD in 
OSSIC be the same as found in the GCINTU table in the TIRKS System for both 
disconnect and DOP orders. 


— If GOC schedules IAD based on intervals at DD completion, CIMAP/SSC will not receive the IAD 
date when the order is logged in CIMAP/SSC but only at DD completion. Dates (DVA, IAD) 
that GOC sends to the Status Reporter after DD completion will be handled like reschedules. 
CIMAP/SSC can only handle these “reschedules" if objective dates were scheduled for these 
events when the order was logged in CIMAP/SSC using calculated dates in the OSSIC tables. 


— For special processing associated with DOP orders, there is a separate OSSIC table other than 
the one used for regular disconnects for DOP orders. The action key in this table is "P". On DD 
completion, the software will not back complete DVA on DOP orders. 


¢ The following action is taken by CIMAP/CC to handle disconnect processing at order log time: 


— If IAD date appears in a STEP table for disconnects not present in GOC, it is calculated based 
on an interval in the CC Report Date Table. 


— CIMAP/CC supports a separate STEP table for DOP orders. If a STEP table for DOP is not 
found, the STEP table for regular disconnects is used. Note: CIMAP/CC cannot support a DVA 
date that is after DD as allowed on DOP orders; it. is recommended that DVA not be used in the 
DOP Step table. 


— GOC generates IAD dates when DD is completed and the dates are sent to the Status Reporter. 
The Status Reporter handles this situation like date reschedules and notifies CIMAP/CC. 


« GDS does not post. the IAD date back to GOC and is not impacted by GOC’s disconnect: processing. 
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L. Order Cancellation 
After orders are logged in the TIRKS System and received by Operations, they can be cancelled. 


e The following action takes place in GOC in processing cancellations: 


— The cancel is logged in GOC as an order supplement with a supplement type of C (cancel). 


— The order status goes to EK or PK depending on whether the order status was Entry (E) or 


Pending (P) at the time of cancellation. 


— Completion of all uncompleted critical dates is blocked except for Due Date (DD). 


— On DD completion, the order status goes to In-Effect Cancel (IK). 
— GOC has an auto-completion flag on GCRRO2. If this flag is set to "yes", GOC will auto 


complete DD at the time the cancel supplement is logged if the order status is E or P with no 
RID date (as in DOP orders). If either of these conditions is met, the Order Status will go from E 
or P to IK directly when the cancel supplement is logged. This feature can potentially affect 
CIMAP/SSC for disconnect orders that are received at order log time. Currently GOC sends this 
auto-completion over to CIMAP with a status of PK rather than IK placing CIMAP and GOC 
out of sync until the order is completed in CIMAP. 


GOC can cancel a disconnect order after DD has been completed if there is an IAD date. The 
order status goes from PX to PK and DD completion is backed out. 


e The following action takes place in Operations when an order cancellation supplement is received 
from GOC by the Status Reporter. 


NOTE - Operations CANNOT support a 
cancel of a cancel implemented by updating 


STAT on GCDBC. 


— The Status Reporter will notify CIMAP/SSC, CIMAP/CC, and GDS as appropriate. 
— In CIMAP/SSC, the system will place an entry on the LOG, and a calendar entry will be made 


3-28 


on today’s worklist of the position that has the next scheduled event. The entries will state 
“Pending Cancel Rec’d”. 


As in GOC, CIMAP/SSC will block completions on any uncompleted events except for DD. For 
disconnect orders where DD is already completed, the system will back out the completion and 
put DD back on the objective dates worklist of the tester who was previously assigned DD. 


Depending on company methods, 


a. The person who had the next uncompleted event on their worklist could be responsible for 
_ completing DD on the PK order after determining that all work done on the order is backed 
out or stopped. 


b. GOC, rather than CIMAP/SSC, would complete the cancel, and the work on the order 
could be backed out or stopped. 


CIMAP/SSC will support the cancellation of a disconnect order after DD is completed if the 
order status is PX, that is, if there is also IAD processing. CIMAP/SSC will back out DD 
complete, and put the DD event back on a worklist. The order status will go from PX to 
PK. Regardless of which system completes DD, CIMAP/SSC would take the following 
action: 


PROPRIETARY — BELLCORE AND AUTHORIZED CLIENTS ONLY 
See proprietary restrictions on title page. 


31 


Generic Dispatch System Release 3.1 User Manual — Part 2 





BR 190-539-311 
Issue 6, August 1989, GDSR 3.1 


c. The Order Status goes from PK to IK. 

d. The pending cancel worklist entries and all calendar events would be removed. 
e. The WORD would be voided. 

f. All Circuit History information would be removed. 


g. The Order and the LOG would remain in the IA and TRACE databases until archiving for 
audit purposes, then removed. 


— CIMAP/CC will receive a notice of a pending cancel from the Status Reporter and will 
¢ Cancel the order in CIMAP/CC if no work has started. 
« Otherwise, review steps will be generated. 
— GDS will receive a notice of a pending cancel from the Status Reporter and take the following 
steps: 


« If the order is an Engineering Service Order (ESO), and the work request(s) are pending 
load (PLD) or pending screen (PSC), GDS will allow the order to be cancelled. 


« If the order is not an ESO and job status is either pending screen or pending load, GDS 
will change the handling code to pending cancel (PCN). 


e If the order is not an ESO and has a conflicting job status (e.g., preassigned or . 
dispatched), GDS will send an exception notice to a printer and place a comment on the 
work request. GDS inhibits any further dispatch processing. To resolve the conflict, the 
work request must return to a job status of pending screen allowing the order to be 
cancelled. 


M. Error Handling 


Using the GOC Interface, jeopardies and date completions can be posted either in GOC or in 
Operations. The posting information is then passed to the other system. Error cenditions may occur in 
the receiving system causing the posting to fail for the following reasons: 


e An Operations Posting Fails in GOC - If a posting of a date is completed in CIMAP/SSC, 
CIMAP/CC or GDS but fails in GOC, the provisioning TCM sends the GOC error message to one of 
the Operations Error Handlers. Each operations system has its own Error Handler. The 
CIMAP/SSC Error Handler enters the GOC error message on the LOG. The user has an option to 
set the error option flags in the SSC-OPTIONS table to have a 


— Calendar entry placed on an appropriate worklist. (GCCAL) 
— Message sent to the SSC LTERM printer (GPRINT) 
— Message sent to the originating LTERM (GCLTERM). 


For errors in CIMAP/CC postings to GOC, TCM will send error messages to the CIMAP/CC Error 
Handler for action. 


For errors in GDS, the GDS Error Handler will send an exception notice based on the entries in the 
GDS Exceptions table. 


For errors in INE postings to GOC, TCM will send error messages to the OPS/INE Error Handler 
which sends an exception notice to the PCO LTERM as specified in the DCS Administration Record 
(DCS ADM). 
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The major reasons an operations posting would fail in GOC are as follows: 


— For jeopardy and MFC postings - GOC has an internal table to validate jeopardy/MFC codes 
posted in GOC. If a code is not in this table, the posting will fail. CIMAP/SSC has an option 
(VALJEOP) in the SSC-OPTION table to validate jeopardy/MFC codes before sending them to 
GOC. If set to "Y", the system validates the code against the CIMAP/SSC internal table which 
is loaded to CIMAP/SSC using the same data as GOC. If the users select this option and keep 
the internal tables in both systems in sync, then all jeopardies/MFC codes should post 
successfully in GOC. CIMAP/CC does not support a validation option. GDS has its own TTS 
jeopardy validation table (GDS HDLGCODE) which should be kept in syne with GOC. 


— For Critical Date Posting - To successfully post critical date completions in GOC, certain rules 
set in the TIRKS Date Rules Update table (GCDRU) must be met. This table is keyed by Event 
name (DVA, WOT.....) Order Class, Admin. Area, and Reference Date. The reference date is the 
calendar date when a set of rules apply. Not all rules are user modifiable, but an example of 
how a company could modify date rules is: 


a. As of December 30, a company could change the DVA MFC REQUIRED flag from "N" to 
"Y". The result is that all overdue DVA dates would require an MFC code for posting after 
December 29. If not present, the posting would fail. 


Given all the possible posting rules that can be changed by the user, Table 3-6 shows the actions 
taken by the Status Reporter to prevent Operations systems from posting date completions that 
might fail in GOC. 


A GOC Posting Fails in CIMAP/SSC - If a date completion is posted successfully in GOC but fails 
in CIMAP/SSC, the CIMAP/SSC Error Handler will react to this error within the CIMAP System. 
No notification of the failure will be sent to GOC. The error message generated by the failure will 
be placed on the LOG and a message will be sent to the SSC LTERM printer. The major reason 
why a completion would fail in CIMAP/SSC is if the IMD EDITS have not been met at DD 
completion. CIMAP/SSC will not block item level completions from the GOC if there are 
outstanding CWLs on the order. 


CIMAP/CC is not impacted by this possibility since CIMAP/CC does not accept date completions 
from GOC. 
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Table 3-6. Status Reporter (SR) Date Rule Handling 


e CIMAP WILL MINIMIZE ERROR FALLOUT BY PROVIDING A SUBSET OF GOC DATE RULES 
IN CIMAP. 


e CIMAP/SSC MAINTAINS OPTIONAL VALIDATIONS FOR JEOPARDY AND MFC CODES. NO 
VALIDATION IS DONE BY CIMAP/CC. GDS HAS ITS OWN TTS VALIDATION TABLE. 


DATE RULE HANDLING BY STATUS REPORTER (SR 

ACTUAL DATE REQUIRED SR WILL ALWAYS SEND GOC THE ACTUAL 

Y/N COMPLETION DATE AS POSTED IN CIMAP OR GDS. 

BY REQUIRED (Y/N) SR WILL ALWAYS SEND GOC THE INITIALS FOR ALL 
CRITICAL REPORT DATES. 

GRACE DAYS (0-99 GOC IMPACT ONLY 

MFC REQUIRED (Y/N) CIMAP/SSC MAINTAINS A "MFC EVENT EDITS" TABLE 


MIRRORING THE GOC RULE. THE TABLE WILL 
INDICATE WHETHER AN MFC CODE IS REQUIRED FOR 





. PAST DUE EVENT COMPLETIONS. CIMAP/CC AND GDS 
DO NOT. GDS DOES REQUIRE A MFC FOR PAST DUE DD. 
ALLOWED ON HOLIDAY IMPACT ON GOC WHEN LOGGING ORDERS. SR WILL 
(Y/N) ACCEPT AND COMPLETE ALL GOC DATES AS 
RECEIVED. : 
AUTO_JEP BY LEVEL SR DOES NOT RECEIVE AUTO_JEPS FOR GOC BECAUSE 


THEY ARE GENERATED BY A BMP RUN. 
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N. Tracking Levels 
e There are four levels of tracking for GOC: 
— Order level 
— CCR level - For multipoint circuits 
— Circuit level (item level) 
— CKL/CWL level. 


In GOC, a user can post jeopardies/completions at all levels. There are also rules in the TIRKS 
Date Rules (GCDRU) that govern whether there will be upward propagation of completions to the 
next tracking level for each event. For example, when the last CWL location completes WOT, GOC 
will propagate that completion upward to the item level WOT date. 


For CIMAP/SSC - Because orders are received in CIMAP/SSC at RID one item at a time the only 
completions that make sense in this environment are item level completions. CIMAP/SSC can not 
guarantee that all items on an order were issued to SSC or that any one SSC would have all the 
items associated with a particular order. 


However, CIMAP/SSC does have an Installation Grouping feature (OSSGI) which allows the user to 
group order/items by Project, RO, TGAC, or Base CLO. The OSSGI format allows the user to bulk 
process date completions. An order level FIND on OSSGI will initiate a bulk completion of all items 
in an order for a given event. The same holds true if the user did a FIND using CCR; there would 
be a bulk completion of all items on the CCR FIND. For more details see Section 4 where OSSGI is 
explained in detail. 


CIMAP/SSC relies on GOC upward propagation rules to propagate item level completions to the 
Order or CCR level. For example, if CIMAP/SSC did not have all the items on a particular order 
and OSSGI was used to bulk complete Due Date for all items on the order, then when GOC 
completed processing the last item level DD from CIMAP/SSC, GOC would propagate the DD 
completion upward to the Order level. 


oy 


DVA is the only date where this processing does not apply. GOC does not upward propagate 
completion from one level to another for DVA at any level. CCR and Order level DVA completions 
must be posted in GOC. 


e GDS and CIMAP/CC do not support four level tracking. 
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O. CIMAP-GDS-TIRKS Machine Architecture 


The CIMAP-GDS-TIRKS Interface architecture fully supports multiple TIRKS machines feeding the 
same CIMAP-GDS machine, but only partially supports one TIRKS machine feeding multiple CIMAP 
machines. 


e Multiple TIRKS machines - One CIMAP-GDS machine can receive orders from multiple TIRKS 
machines. To track which orders came from which TIRKS machine, a circuit source field is stored in 
the CIMAP databases, as defined in the SEC TO SOURCE table. This code identifies the 
originating TIRKS machine for each circuit. It is used by the Status Reporter when posting 
jeopardies and completions on an order to identify which TIRKS machine should receive the posting 
message. 


— If GDS is on a separate processor, the GDS machine can also receive orders from multiple TIRKS 
machines. GDS is sent the TIRKS SEC code for each order it receives. This SEC code is used by 
the Status Reporter to post back to the correct TIRKS machine. 


Multiple CIMAP machines - As of TIRKS Release 14.2, the CIDIST SSC INFO and OPTS LINK 
SSC tables are keyed by MCO/OCO/CCO rather than being company level tables. This allows the 
user to specify different MSC links for different MCOs/OCOs/CCOs; that is, orders can be 
distributed to different CIMAP machines based on MCO/OCO/CCO, The following cases are not 
supported by the present architecture: 


— CIDIST cannot distribute the same order to more than one CIMAP machine. If an operating 
company has: circuits whose installation is tracked by SSC1 on CIMAP machine A and the 
maintenance of that circuit is controlled by SSC2 on CIMAP machine B, the WORD and circuit 
history information must be in both machines. Currently the only available procedure for 
handling this is, that once the circuit is IE, the CPC must update the MCO field on WA and 
reissue the IE order to SSC2 and then change the MCO field back to allow subsequent orders (D, 
RN, R) to flow to SSC1. 


— Multiple CIMAP machines are only supported for installation activities. Maintenance activities 
are not supported; that is, a mechanized hand off can not be done by SSC on CIMAP machine A 
to a central office on CIMAP machine B. 


— On one TIRKS machine, CIMAP/DOC can only send CIMAP/CC and GDS orders and location 
information to one CIMAP machine, one GDS machine, and one NIS machine for OPS/INE. 
OPTS LINK CC, OPS LINK INE, and OPTS LINK SSDAC are company level tables so only one 
MSC link can be specified. The CIMAP/CC machine need not be the same as the machine on 
which CIMAP/SSC resides. However, the CIMAP/CC machine must have some of the 
CIMAP/SSC modules and tables turned up so that the Status Reporter is available for passing 
posting information to GOC. If CIMAP/CC does reside on a different machine, the mechanized 
maintenance interface is not supported. 


— Like CIMAP/CC, OPTS LINK SSDAC is a company level table thus CIMAP/DOC can send 
orders to only one GDS machine. However, GDS need not be on the same processor as CIMAP 
and both installation and maintenance interfaces to CIMAP/SSC are supported including 
JUMP/FIND capabilities between systems. 


CIMAP to GDS - One GDS machine cannot support an architecture consisting of multiple CIMAP 
machines, nor can CIMAP support a multiple machine architecture to GDS. 


« CIMAP to NIS (OPS/INE) - One NIS machine cannot support. an architecture consisting of multiple 
CIMAP machines; nor can CIMAP support a multiple machine architecture to NIS. 
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3.1.18 GDS - SOAC Interface 
A. Introduction 


One of the innovative features of the Generic Dispatch System is its ability to facilitate the receipt, 
dispatch, close, and tracking of service orders. The purpose of this section is to provide a high level 
description of the flow of data between the Service Order Processor (SOP), Service Order Analysis and 
Control System (SOAC), TIRKS Communication Module (TCM), and GDS. This user guide will contain 
a summary of the interface as described in the document titled "SOAC-GDS Interface Requirements and 
FCIF Specification: Pots, Non-Designed and Designed Special Services". If more detail is needed 
concerning the message structures, aggregate and TAG values, or formats of these data messages, refer 
to this document. 


The following paragraphs discuss the major functions of the components of the SOAC/GDS interface. 
B. Service Order Analysis and Control System (SOAC) 


Service orders are distributed by the SOP to SOAC. Upon receiving service orders and during the life of 
the order, SOAC will perform several functions. Some of these GDS specific functions are described 
below: 


e Determine GDS involvement and create the needed message structures to send to GDS. GDS 
involvement is determined by the type of order, order pass, presence, or absence of the ADSR FID, 
the class of service USOC, and the GDS conversion status of the wire centers on the order. To be 
considered GDS involved, an order must meet all five conditions. 


« Perform the service order parse. In this step of the process, SOAC will copy the data fields from the 
service order that are needed by GDS in order to build a work request. 


« Create the planning message (NET1) and send to TCM. 

« Upon completion of automatic assignment, create the assignment message (NET2) and send to TCM. 
e Process positive and negative responses from TCM. 

e Provide inquires and reports related to SOAC GDS activities. 


During the process of sending messages to TCM/GDS, SOAC formats all the data needed by GDS into a 
structure known as Flexible Computer Interface Format (FCIF). This structure, consisting of sections, 
aggregates, and TAGs, is arranged in a format similar to an outline. FCIF is a standard method of 
formatting data in order to build the preliminary interface between two computer systems. The data, 
after being placed into this preliminary arrangement, simplifies TCMs task of editing the content of the 
message and reformatting the data into the final format (DSECT) that will be processed by GDS. 


C. TIRKS Communication Module (TCM) 


The TIRKS Communication Module (TCM) resides within GDS. TCM allows communication between 
one application residing with TCM in one IMS copy of an IBM computer and another external TCM 
System or another non-TCM System (SOAC). TCM receives the input message in the GDS scenario 
from SOAC in a format known as FCIF, and prepares and formats the data in a manner that is 
acceptable to GDS programs. 


TCM provides the following features within the GDS environment: 


e Places data in formats that are acceptable to remote system (SOAC). 


PROPRIETARY — BELLCORE AND AUTHORIZED CLIENTS ONLY 
See proprietary restrictions on title page. 


3-34 


Generic Dispatch System Release 3.1 User Manual — Part 2 





37 


Generic Dispatch System Release 3.1 User Manual — Part 2 





BR 190-539-311 
Issue 6, August 1989, GDSR 3.1 


e Places data in formats that are acceptable to target systems (GDS). 
e Automatically determines the communication path over which to route the messages. 
« Stores the transmitted messages until the receiving system has acknowledged (positive or negative). 


e Ensures that the related messages are sent in proper sequence by holding the later messages until the 
earlier message has been transmitted and a positive acknowledgement has been received. 


e Message queuing upon link failures. 
e Automatically resends messages upon link restorals. 


e Stores errors during processing of incoming messages and stores negative acknowledgements from 
target applications. 


e TCM provides an on-line capability to correct, resend, or delete messages that error during 
processing. 


e TCM provides statistical data on processed messages that can be viewed on-line via TQS reports. 
TCM contains databases that are used to process messages. They are as follows: 


e Transaction Log Database (TLOG) 
This database is used to log messages that must be retained while awaiting a positive 
acknowledgement from the target application. Messages are also stored here when the initial 
processing caused an error or the messages are awaiting a positive acknowledgement from the target 
application. 


Deferred Message Queue Database (SENDQ) 

This database is used to store messages when processing is deferred because of link failures. 
Messages that are deferred and stored in the SENDQ database can be removed in one of two ways. 
The first method is an automatic check of the deferred message counters for each link in the SEC 
database when the link becomes available. The messages that are queued are resent to the Route 
Administration module for processing and subsequent deletion from database, The second method of 
deletion of queued records from the SENDQ database is from the format GMPMSG screen. From 
this screen, the user can move non-acknowledgement messages to the TLOG database for subsequent 
resubmittal or deletion. 


Network System Entity Code Database (SEC) 

This database is used to contain information about each of the operational systems that TCM must 
communicate with. Each of the operational systems is defined with a unique system entity code 
(SEC). Information about the communication links to and from the various SECs is stored here also. 
The SEC database can be accessed using the GMPNET and GMPSTS screen formats. 


Terminal Database 

This database provides a method by which the user can update records in the TLOG database. 
Whenever format GMPMSG is used to retrieve a record from the TLOG database, the record is 
placed in the Terminal Database. While a copy of a message is stored simultaneously in the TLOG 
and Terminal Database, the message is "protected" in that other users will not be able to access the 
message in the TLOG database. This will eliminate the possibility of duplicate updates by two users 
at the same time. 


PROPRIETARY — BELLCORE AND AUTHORIZED CLIENTS ONLY 
See proprietary restrictions on title page. 


3-35 


Generic Dispatch System Release 3.1 User Manual — Part 2 





BR 190-539-311 
Issue 6, August 1989, GDSR 3.1 


D. Acknowledgement Messages 


Acknowledgements from GDS to TCM are referred to as class 2 messages. They are either positive or 
negative. Positive acknowledgements may or may not contain "Warnings". Messages that are 
acknowledged without warnings are deleted from the TLOG database. For those acknowledgements 
that do contain warnings, a positive response is sent in FCIF format to the originating system (SOAC) 
and an exception notice is printed for the user’s analysis. 


When GDS receives a message from TCM that is unacceptable for processing, an exception notice is 
printed for the user and a negative acknowledgement is sent back to the originating system (SOAC). 
The user then initiates steps for error processing. 


E. Error Processing 


Errors during processing of messages can occur on class 1, class 2, or class 3 messages. Class 1 messages 
or class 3 are application to application messages (SOAC to GDS). 


Class 2 messages are acknowledgement messages (GDS/TCM to SOAC). Errors encountered can be of 
six possible varieties. They are as follows: 


¢ TCM header validation errors 

e TPAM parsing errors 

e TPAM translation errors 

e TPAM mapping errors 

« TPAM general errors 

e Application errors due to negative acknowledgements. 


For more information concerning error reconciliation or general administration of TCM, refer to BR 
190-539-301, BR 190-539-302, BR 190-539-303, BR 190-539-304, BR 190-539-305 and BR 190-539-404. 


F. Generic Dispatch System (GDS) % 


On most service orders, GDS receives two messages from SOAC. The first message is called a 
precompletion planning message, sometimes referred to as the NET1, which contains service order image 
minus the assignment section. The purpose of the planning message in GDS is to initiate basic pricing 
for long range load forecasting, as well as for routing to determine work center. The second message 
type GDS will receive for each order is called an assignment message, sometimes referred to as the 
NET2. This message is created in SOAC upon receipt of the LFACS assignment data and is passed to 
GDS along with the assignment section of the Service Order Image. The purpose of the assignment 
message is to produce the assignment section of the work request. When GDS receives the assignment 
message, the work request is subjected to the logging process of screening, mapping, zoning, typing, and 
pricing. After these functions are successfully completed, the work request is either a candidate for 
automatic completion within GDS and subsequent closeout to the SOP or placed in the dispatch pool 
with a jobstatus of "PLD" or "PWD". If job logging was not successful, the work request will have a 
jobstat of "PSC". In this case, manual assistance from the ICC/SSDAC personnel will be necessary in 
order to determine the proper status of the work request. 


There are times when GDS will not have enough data from SOAC to completely flow the order through 
job logging. To aid the end user in analysis of these types of orders, GDS will automatically set 
handling codes identifying these order passes. 
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Handling codes that will be set as a result of job logging messages from SOAC that are unique are as 
follows: 


CALL FOR ASSIGNMENT - "CFA" 


GDS will occasionally receive an assignment message without the FCIF assignment section. This 
assignment message will contain the CFA TAG set to "Y". This TAG tells GDS management that 
the technician being dispatched must call the LFACS personnel and inform them of the necessary 
data, i.e., terminal address, cable and count, that is needed to complete the facility assignments. 
To help the analysis of the order flow between SOAC and GDS, an additional system generated 
Handling Code of "CFA" will be created when the CFA TAG is received by GDS. 


OUTER LOOP FLAG - "TDO" 


Certain order types cannot be assigned by LFACS. When these orders are received by SOAC, 
they are manually assigned "outer loop", which sets the TDO flag in the OCTL and WCTR 
aggregates. Orders assigned using the outer loop method do not create the assignment section in 
FCIF. Therefore, GDS will not job log the order pass completely. To help the analysis of TDO 
orders, GDS will automatically populate the HDLGCODE field with a system-generated handling 
code of "TDO". 


NO ASSIGNMENT SECTION FLAG - "NA" 


The No Assignment Section Flag may appear in the OCTL of the planning message or the OCTL 
and WCTR aggregates of the assignment message. The TAG is set in the OCTL of the 
assignment message only when all the WCTR aggregates contain the NA TAG set to "Y". 


If the NA TAG is set to "Y" in the OCTL of the planning message, SOAC will not send an 
assignment message to GDS. 


On some orders, GDS will receive planning messages without the NA TAG set but the assignment 
messages will have the NA TAG set to "Y" in the OCTL and WCTR aggregates. This will occur 
when the assignment involvement is for touch tone and custom calling features. The NA TAG is 
set on these orders because the assignments appear in the Service and Equipment section of the 
service order, not the assignment section. 


To help analysis of orders containing the NA TAGs, GDS will automatically populate the 
HDLGCODE field with a system-generated handling code of "NA". 


FACILITIES NOT AVAILABLE FLAG - "FNA"™" 


The Facilities Not Available Flag appears in the OCTL and CTL aggregates. The purpose of the 
FNA flag is to indicate to the receiving system that facility assignments are not available at the 
present time. 


In the OCTL aggregate, the value of the FNA TAG will be "C" or "U". The FNA TAG will be set 
to "C" if the CFA TAG is set to "Y" for any circuit termination in the LFACS Assignment 
Request Response. 


The FNA TAG will be set to "U" in the OCTL aggregate if an unsolicited assignment response 
from LFACS is received by SOAC and facility assignments are not yet available. This will occur 
on small business customers when there is a disconnect order due at a location and a New connect 
order for a different customer is due at the same location. If the due dates are compatible, LFACs 
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will assign the "N" order with the "D" order’s cable and pair. However, if the “D" order customer 

changes the due date for disconnecting service, and LFACS cannot find facilities for the "N" order ~ 
customer, an unsolicited assignment response from LFACS is sent to SOAC with the FNA TAG set 

to "U". 


In the CTL aggregate, the value of the FNA TAG is "C" if the CFA TAG is set to "Y" on any 
circuit termination in the LFACS Assignment Request Response. The FNA TAG will not be set in 
the CTL aggregate if an unsolicited response is received from LFACS and assignments are not 
available. 


To help in the analysis effort, GDS will automatically populate the JOBSTAT field with "PFA" 
and the HDLGCODE field with a system generated handling code of "FNA" if the FNA TAG is 
set to "U" in the OCTL aggregate only. 


MANUAL ASSISTANCE - "MA" 


If GDS receives a planning message from SOAC with the MA TAG set to "Y", GDS will 
automatically set a handling code of MA. 


INCOMPLETE MANUAL ASSISTANCE -"MAI" 


If GDS receives a planning message from SOAC with the INCP flag set to "Y", and the MA flag 
set to "Y", GDS will automatically set a handling code of "MAI". 


G. Precompletion Planning Message 


When a planning message is sent to GDS by SOAC, it will contain a copy of the service order image as 
well as certain fields from the service order that are needed by GDS as explained above. These fields 
are referred to as equipment and testing USOCs and FIDs. Examples of FIDs on data items that are 
parsed from the service order and sent to GDS are defined below: 


FID DEFINITION S.0. SECTION 
™N Main TN IDENT. 
CLS,CLT,CKT,PSM Common Language Circuit S&E 
SIT,SIS,DID,CKR Identification; Service S&E 
OGO,PX,TER,TLI Code and Modifier; S&E 
ORD Order Type (N,T,D,F,C) IDENT. 
ORD Order Number IDENT. 
ORD Correction Suffix IDENT. 
cs Class of Service IDENT. 
scs Circuit Class of Service S&E 
DD Due Date/Access Info IDENT. 
sD Sub Date/Access Info IDENT. 
SLS Sales Origination Code IDENT. 
SLSN Sales Origination Code Control 
NCON Sales Origination Code Control 
ACNA Abbreviated Access Carrier Name INDENT. 
CCNA Customer Carrier Names 

Abbreviation IDENT. 
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DEFINITION 


Administration of Designed 
Services Review 

Official Company Services 
Indicator 

To Due Date 

From Due Date 

Service Order Application Date 
Design Verified Assigned Date 
Frame Continuity Date 

Plant Test Date 

Records Issue Date 

Wired and Office Tested Date 
Participation Customer Status 
Complete with Related Order 
Related Order 

Service Address 

Service Address 

Listed Address 

Location 

Service/Listed Address 
Purchase Order Number 
Overall Control Office CLLI 
Customer Name 

Customer Name 

Customer Name 

Customer Name 

Customer Name 

COMMON LANGUAGE Segment 
Number 

Facilities Address and 

Circuit Location Number 
Facilities Address and 

Circuit Location Number 
Circuit Location Number 
Point of Interface 

Access Customer Terminating 
Location 

Service Name 

Local Contact Name 

and Telephone Number 
Maintenance Control Office 
Design Contact Name and 
Telephone Number 

Billing Telephone Number 


8.0. SECTION 


IDENT/S&E 


IDENT. 
IDENT. 
IDENT. 
IDENT. 
Control 
Control 
Control 
Control 
Control 
Billing/IDENT 
IDENT. 
IDENT. 
LIST 
LIST 
LIST 
LIST 
LIST 
BILLING 
CONTROL 
LIST 
LIST 
LIST 
LIST 
LIST 


S&E * 
S&E 
S&E 
S&E 
S&E 


LIST 
S&E 


S&E 
S&kE 


CONTROL 
BILLING/S&E 
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H. Assignment Message 


The assignment message is created in SOAC after processing the service order through LFACS and = 
COSMOS. The assignment message or NET2 consists of the facility assignments in FCIF with a copy of 

the assignment section of the Service Order Image. Unless an order falls out for Manual Assistance 

(MA) during NET1 processing, the assignment message will be received by GDS soon after receiving the 

planning message. When GDS receives the assignment message from SOAC, job logging begins. Job 

logging consists of service order screening, routing, mapping, zoning, typing, and pricing. Refer to 

Section 3.2 of this manual for further information concerning the job logging functions. 


There are no FIDs parsed from the service order for the assignment message as is done for the 
precompletion planning message. There are, however, "TAGs" or data items associated with the outside 
plant assignments that are sent to GDS from SOAC. Some of those data items received by GDS in the 
assignment section are defined below: 


FID DEFINITION 8.0. SECTION 

RSP Restoration Priority S&E 

SSM Safeguard Measures S&E 

SSP Safeguard Measures S&E 

NCI Network Channel Interface 
Code S&E 

SA,LA USOC Address, i.e., the 

ACA,CKL address SOAC determines to 

DPA be associated with equipment = 
or testing USOCs LIST/S&E 
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DATA ITEM DEFINITION 


"CA" Cable Identifier 

"PR" Pair Identifier 
“TERM" Terminal Address 
"ENC" Encapsulated Flag 

"BP" Binding Post Number 
“BPCL" Binding Post Colors 

"wi" Work Instructions 


“WOL" Wired Out Of Limits 
"WOLD" Data Associated with WOL Facility 


"BCT" Indicates a Broken Connect Through 
Facility 

"BOF" Indicates a Broken Connected 
Facility 

"PGST" Pair Gain System Type 

"ADE" Air Dryer Flag 

"CPC" Cable Pressure Contactor Flag 

"CPT" Cable Pressure Transducer Flag 


"LST" LST number 
“LSTF" LST flag 
"ITM" LST item number 


"ACT" Indicated Action to be Taken on 

ie Circuit Termination 
"SSM" Special Safeguarding Measures Flag 
"SSP" Special Service Protection Flag 
"RTF" Transmit /Receive Flag 


The data items defined in this document are only the items either derived from FIDs from the service 
order or produced within LFACS. There are, however, several other data times or "TAGs" involved in 
the interface. For more information, refer to the SOAC/GDS interface specification document 
mentioned in the beginning of this section. 
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This list contains the short names and full titles of switch tables for the Nortel DMS product family. 


KSETFEAT (ACDNR) 
KSETFEAT (ACOU) 
KSETFEAT (ACRJ) 
KSETFEAT (AFC) 
KSETFEAT (AIN) 
KSETFEAT (AOC) 
KSETFEAT (AR) 
KSETFEAT (ASL) 
KSETFEAT (ASP) 
KSETFEAT (AUD) 
KSETFEAT (AUL) 
KSETFEAT (AUTODISP) 
KSETFEAT (BBGI) 
KSETFEAT (BC) 
KSETFEAT (BCLID) 
KSETFEAT (BLF) 
KSETFEAT (CCV) 
KSETFEAT (CCBS) 
KSETFEAT (CFB) 
KSETFEAT (CFD) 
KSETFEAT (CFDVT) 
KSETFEAT (CFFPOVR) 
KSETFEAT (CFTB) 
KSETFEAT (CFTD) 
KSETFEAT (CRUIF) 
KSETFEAT (CFX) 
KSETFEAT (CFXDNCT) 
KSETFEAT (CFXVAL) 
KSETFEAT (CIDSDLV) 
KSETFEAT (CIDSSUP) 
KSETFEAT (CIF) 
KSETFEAT (CLI) 
KSETFEAT (CNF) 
KSETFEAT (COT) 
KSETFEAT (CPR) 
KSETFEAT (CPU) 
KSETFEAT (CRBL) 
KSETFEAT (CSMI) 
KSETFEAT (CTD) 
KSETFEAT (CUG) 
KSETFEAT (CW) 
KSETFEAT (CWD) 
KSETFEAT (CWT) 
KSETFEAT (CXR) 
KSETFEAT (DASK) 
KSETFEAT (DBC) 
KSETFEAT (DCC) 
KSETFEAT (DCPK) 
KSETFEAT (DDI) 
KSETFEAT (DIN) 
KSETFEAT (DMCT) 
KSETFEAT (DND) 


Automatic Call Distribution Not Ready (Feature ACDNR) Subtable 
Additional Call Offering - Unrestricted (Feature ACOU) Subtable 
Anonymous Caller Rejection (Feature ACRJ) Subtable 

Additional Functional Calls (Feature AFC) Subtable 

Advanced Intelligent Network (Feature AIN) Subtable 

Advice of Charge (Feature AOC) Subtable 

Automatic Recall (Feature AR) Subtable 

Agent Status Lamp (Feature ASL) Subtable 

Alternate Service Provider (Feature ASP) Subtable 

Automatic Dial (Feature AUD) Subtable 

Automatic Dial (Feature AUL) Subtable 

Automatic Display (Feature AUTODISP) Subtable 

Basic Business Group ISDN (Feature BBGI) Subtable 

Bearer Capability (Feature BC) Subtable 

Bulk Calling Line Identification (Feature BCLID) Subtable 

Busy Lamp Field (Feature BLF) Subtable 

Call Covering (Feature CCV) Subtable 

Call Completion to Busy Subscriber (Feature CCBS) Subtable 

Call Forward Busy (Feature CFB) Subtable 

Call Forward Don't Answer (Feature CFD) Subtable 

Call Forward Don't Answer Variable Timer (Feature CFDVT) Subtable 
Call Forward Fraud Prevention Override (Feature CFFPOVR) Subtable 
Call Forward Timed for CFB (Feature CFTB) Subtable 

Call Forward Timed for CFD (Feature CFTD) Subtable 

Call Forward Universal Intragroup Fixed (Feature CRUIF) Subtable 
Call Forwarding (Feature CFX) Subtable 

Call Forwarding per DN per Call Type (Feature CFXDNCT) Subtable 
Call Forwarding Validation (Feature CFXVAL) Subtable 

Caller ID Delivery and Suppression Delivery (Feature CIDSDLV) Subtable 
Caller ID Delivery and Suppression (Feature CIDSSUP) Subtable 
Controlled Interflow (Feature CIF) Subtable 

Calling Line Identification (Feature CLI) Subtable 

Flexible Station-Controller Conference (Feature CNF) Subtable 
Customer Originated Trace (Feature COT) Subtable 

Datapath Call Path Restoration (Feature CPR) Subtable 

Call Pickup (Feature CPU) Subtable 

Call Reference Busy Limit (Feature CRBL) Subtable 

Call Screening, Monitoring, and Intercept (Feature CSMI) Subtable 
Carrier Toll Denied (Feature CTD) Subtable 

Closed User Group (Feature CUG) Subtable 

Call Waiting (Feature CW) Subtable 

Dial Call Waiting (Feature CWD) Subtable 

Call Waiting (Feature CWT) Subtable 

Call Transfer (Feature CXR) Subtable 

Display Agent Status Key (Feature DASK) Subtable 

Call Reference Busy Limit (Feature DBC) Subtable 

Deactivate Conference Facility (Feature DCC) Subtable 

Directed Call Park (Feature DCPK) Subtable 

Direct Dialing In (Feature DDI) Subtable 

Denied Incoming (Feature DIN) Subtable 

Deny Malicious Call Termination (Feature DMCT) Subtable 

Do Not Disturb (Feature DND) Subtable 
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KSETFEAT (DQS) 
KSETFEAT (DQT) 
KSETFEAT (DRING) 
KSETFEAT (DROP) 
KSETFEAT (EBO) 
KSETFEAT (ECM) 
KSETFEAT (EMK) 
KSETFEAT (EMW) 
KSETFEAT (FAA) 
KSETFEAT (FC) 
KSETFEAT (FCTDINT) 
KSETFEAT (FXR) 
KSETFEAT (GIAC) 
KSETFEAT (HF, 
HFMUTE, MUTE, 
SOFTKEY) 

KSETFEAT (ICM) 
KSETFEAT (INSPECT) 
KSETFEAT (ISA) 
KSETFEAT (JOIN) 
KSETFEAT (KSH) 
KSETFEAT (LMOH) 
KSETFEAT (LOB) 
KSETFEAT (LOCAL) 
KSETFEAT (LPIC) 
KSETFEAT (LSPSO) 
KSETFEAT (LVM) 
KSETFEAT (MBSCAMP ) 
KSETFEAT (MCH) 
KSETFEAT (MCT) 
KSETFEAT (MIPHONE) 
KSETFEAT (MRFM) 


KSETFEAT (MSB) 
KSETFEAT (MWIDC) 
KSETFEAT (MWORY) 
KSETFEAT (MWT) 
KSETFEAT (NDNAP ) 
KSETFEAT (NGTSRVCE) 
KSETFEAT (NRS) 
KSETFEAT (OBS) 
KSETFEAT (OLS) 
KSETFEAT (PBL) 
KSETFEAT (PCACIDS) 


KSETFEAT (PF) 

KSETFEAT (PIC) 
KSETFEAT (PRK) 
KSETFEAT (PRL) 
KSETFEAT (PRV) 
KSETFEAT (QBS) 
KSETFEAT (QCK) 
KSETFEAT (QTD) 
KSETFEAT (RAG) 
KSETFEAT (RMB) 
KSETFEAT (RSUS) 
KSETFEAT (SACB) 
KSETFEAT (SCF) 
KSETFEAT (SCL) 


Display Queue Status (Feature DQS) Subtable 

Display Queue Threshold (Feature DQT) Subtable 

Distinctive Ringing (Feature DRING) Subtable 

Drop (Feature DROP) Subtable 

Executive Busy Override (Feature EBO) Subtable 

Extended Call Management (Feature ECM) Subtable 

Emergency Key (Feature EMK) Subtable 

Executive Message Waiting (Feature EMW) Subtable 

Forced Agent Availability (Feature FAA) Subtable 

Flexible Calling (Feature FC) Subtable 

Full Carrier Toll Deny for International Carriers (Feature FCTDINT) Subtable 
Fast Transfer (Feature FXR) Subtable 

Group Intercom All Call (Feature GIAC) Subtable 

Hands-Free Control (Feature HF, HFMUTE, MUTE, SOFTKEY) Subtable 


Intercom (Feature ICM) Subtable 

Inspect (Feature INSPECT) Subtable 

In-Session Activation (Feature ISA) Subtable 

Conference Join (Feature JOIN) Subtable 

Key Short Hunt (Feature KSH) Subtable 

Line Music on Hold (Feature LMOH) Subtable 

Line of Business Code (Feature LOB) Subtable 

Local (Feature LOCAL) Subtable 

Primary Intra-LATA Carrier (Feature LPIC) Subtable 

Local Service Provider Switch Owner (Feature LSPSO) Subtable 
Leave Message (Feature LVM) Subtable 

Meridian Business Set Camp-On (Feature MBSCAMP) Subtable 
Malicious Call Hold (Feature MCH) Subtable 

Malicious Call ID (Feature MCI) Subtable 

Medicated Individual Telephony (Feature MIPHONE) Subtable 
Multiple Appearance Directory Number Ring Forward Manual (Feature MRFM) 
Subtable 

Make Set Busy (Feature MSB) Subtable 

Message Waiting Indication (Feature MWIDC) Subtable 
Message Waiting Query (Feature MWORY) Subtable 
Message Waiting (Feature MWT) Subtable 

Number of DN Appearances (Feature NDNAP) Subtable 
Night Service (Feature NGTSRVCE) Subtable 

Network Resource Selector (Feature NRS) Subtable 
Observe Agent (Feature OBS) Subtable 

Originating Line Select (Feature OLS) Subtable 
Private Business Line (Feature PBL) Subtable 
Privacy Change Allowed Caller ID Delivery and Suppression 
Subtable 

Power Feature (Feature PF) Subtable 

Primary Inter-LATA Carrier (Feature PIC) Subtable 
Call Park (Feature PRK) Subtable 

Privacy Release (Feature PRL) Subtable 

Privacy (Feature PRV) Subtable 

Query Busy Station (Feature QBS) Subtable 

Quick Conference Key (Feature QCK) Subtable 

Query Time and Date (Feature QTD) Subtable 

Ring Again (Feature RAG) Subtable 

Random Make Busy (Feature RMB) Subtable 

Requested Suspension (Feature RSUS) Subtable 
Subscriber Activated Call Blocking (Feature SACB) Subtable 
Selective Call Forwarding (Feature SCF) Subtable 
Speed Calling Long List (Feature SCL) Subtable 


(Feature PCACIDS) 
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KSETFEAT (SCS) 
KSETFEAT (SDY) 
KSETFEAT (SEC) 
KSETFEAT (SHU) 
KSETFEAT (SIMRING) 
KSETFEAT (SLQ) 
KSETFEAT (SLU) 
KSETFEAT (SMDI) 
KSETFEAT (SOR) 
KSETFEAT (SPB) 
KSETFEAT (SSAC) 
KSETFEAT (SUPR) 
KSETFEAT (TBO) 
KSETFEAT (TLS) 
KSETFEAT (TRANSFER) 
KSETFEAT (TRKDISP) 
KSETFEAT (UCDLG) 
KSETFEAT (UCDSD) 
KSETFEAT (VMEADENY) 
KSETFEAT (VMEADN) 
KSETFEAT (WML) 
KSETFEAT (WUCR) 
KSETFEAT (XFER) 
KSETFEAT (XXTRG) 
KSETINV 
KSETKEYS 
KSETLINE 
KSETQCK 

KTGROUP 
KTMINMAX 
KTPARMS 
L2ABNLOG 
L3ABNLOG 

LAC 

LAMABC 

LANGTOQ 
LATANAME 
LATAXLA 

LATTRDR 
LCA6SCRN 
LCAINFO 
LCARNAME 
LCARSCRN 
LCASCRCN 
LCASCRCN.LCASCR 
LCCOPT 

LCLRS 

LCLRSI 

LCMDRINV 
LCMINV 

LDASCRN 

LDTINV 

LENFEAT 

LENFEAT (ADL) 
LENFEAT (AIN) 
LENFEAT (AIOD) 
LENFEAT (AUL) 
LENFEAT (BCLID) 
LENFEAT (CDA) 


Speed Calling Short List (Feature SCS) Subtable 

AT&T Line Study (Feature SDY) Subtable 

Security Code (Feature SEC) Subtable 

Stop Hunt (Feature SHU) Subtable 

Simultaneous Ringing (Feature SIMRING) Subtable 

Single Line Queue (Feature SLQ) Subtable 

Subscribers Line Usage (Feature SLU) Subtable 

Station Message Desk Interface (Feature SMDI) Subtable 
Station Origination Restrictions (Feature SOR) Subtable 
Special Billing Code (Feature SPB) Subtable 

Station Specific Authcode (Feature SSAC) Subtable 
Supervisor (Feature SUPR) Subtable 

Terminating Billing Option (Feature TBO) Subtable 
Terminating Line Select (Feature TLS) Subtable 

Call Transfer ISDN (Feature TRANSFER) Subtable 

Trunk Member Display (Feature TRKDISP) Subtable 
Uniform Call Distribution Login (Feature UCDLG) Subtable 
Uniform Call Distribution Signal Distribution Point (Feature UCDSD) Subtable 
Voice Mail Easy Access Deny (Feature VMEADENY) Subtable 
Voice Mail Easy Access Directory Number (Feature VMEADN) Subtable 
Warm Line (Feature WML) Subtable 

Wake-Up Call (Feature WUCR) Subtable 

Call Transfer ISDN (Feature XFER) Subtable 

XX Trigger (Feature XXTRG) Subtable 

Business Set and Data Unit Inventory Table 

Business Set Feature Keys Table 

Business Set and Data Unit Line Assignment Table 
Business Set and Data Unit Quick Conference Key Table 
Killer Trunk Group Table 

Killer Trunk Minimum Maximum Table 

Killer Trunk Parameters Table 

Layer 2 Abnormality Log Table 

Layer 3 Abnormality Log Table 

Location Area Code Table 

Local Automatic Message Accounting Billing Code Table 
Language-to-TOPS Call Queue Routing Table 

Equal Access Local Access and Transport Area Name Table 
Equal Access Local Access and Transport Area Translation Table 
LINEATTR Dump and Restore Table 

Local Calling Area 6 Screen Table 

Local Calling Area Information Table 

Local Calling Area Name Table 

Local Calling Area Screening Table 

Local Calling Area Screening Control Table 

Local Calling Area Screening Subtable 

Line Class Code Compatible Options Table 

TOPS Calling Tariff to Local Rate Step Table 

TOPS Calling Tariff to Local Rate Step Inactive Table 
Line Concentration Module Drawer Inventory Table 

Line Concentrating Module Inventory Table 

Long Distance Alerting Screening Table (MMP only) 

Line Appearance on a Digital Trunk Inventory Table 

Line Feature Table 

Abbreviated Dialing (Feature ADL) Subtable 

Advanced Intelligent Network (Feature AIN) Subtable 
Auto-Identified Outward Dialing (Feature AIOD) Subtable 
Automatic Line (Feature AUL) Subtable 

Bulk Calling Line Identification (Feature BCLID) Subtable 
Call Diversion (Feature CDA) Subtable 
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LENFEAT (CFFPOVR) 
LENFEAT (CLI) 
LENFEAT (CSDDS) 
LENFEAT (CTD) 
LENFEAT (ESG) 
LENFEAT (ESL) 
LENFEAT (EWAL) 
LENFEAT (FCTDINT) 
LENFEAT (FRO) 
LENFEAT (FRS) 
LENFEAT (HTL) 
LENFEAT (IDND) 
LENFEAT (ILR) 
LENFEAT (INDC) 
LENFEAT (LPIC) 
LENFEAT (LSPSO) 
LENFEAT (MBK) 
LENFEAT (MPB) 
LENFEAT (OUTWT) 
LENFEAT (PIC) 
LENFEAT (RMB) 
LENFEAT (RMP) 
LENFEAT (RMS) 
LENFEAT (RSUS) 
LENFEAT (SC1) 
LENFEAT (SC2) 
LENFEAT (SCMP) 
LENFEAT (SDN) 
LENFEAT (SDY) 
LENFEAT (SHU) 
LENFEAT (SLU) 
LENFEAT (SPB) 
LENFEAT (TBO) 
LENFEAT (WLN) 
LENLINES 
LGINCTRL 
LIMCDINV 
LIMINV 
LIMPTINV 
LINEATTR 
LIUINV 
LKIDTAB 

LMINV 
LMOVCODE 
LMRNG 

LNADMIN 

LNBNV 

LNCODE 
LNETWORK 
LNINV 
LNINVEXT 
LNMPEOC 
LNMTRNAM 
LNPCODE 
LNPOPTS 
LNPRTE 
LNSIGSYS 
LNSIGSYS (DELDIAL) 
LNSIGSYS (N5) 


Call Forward Fraud Prevention Override (Feature CFFPOVR) Subtable 
Calling Line Identification (Feature CLI) Subtable 

Circuit Switched Digital Data Service (Feature CSDDS) Subtable 
Carrier Toll Denied (Feature CTD) Subtable 

Emergency Service Group (Feature ESG) Subtable 

Emergency Service with Ringdown Trunk (Feature ESL) Subtable 
Enhanced WATS Access Line (Feature EWAL) Subtable 

Full Carrier Toll Deny for International Carriers (Feature FCTDINT) Subtable 
Sleeve Lead Control (Feature FRO) Subtable 

Sleeve Lead for Public Fire Reporting System (Feature FRS) Subtable 
Hot Line (Feature HTL) Subtable 

International Do Not Disturb (Feature IDND) Subtable 
International Line Restrictions (Feature ILR) Subtable 
International No Double Connect (Feature INDC) Subtable 
Local Primary Intra-LATA Carrier (Feature LPIC) Subtable 
Local Service Provider Switch Owner (Feature LSPSO) Subtable 
Make Busy Key (Feature MBK) Subtable 

Multi-Party Bridge (Feature MPB) Subtable 

OUTWATS (Feature OUTWT) Subtable 

Primary Inter-LATA Carrier (Feature PIC) Subtable 

Random Make Busy (Feature RMB) Subtable 

Remote Meter Pulsing (Feature RMP) Subtable 

Remote Register Signal Distributor Point (Feature RMS) Subtable 
Requested Suspension (Feature RSUS) Subtable 

Speed Calling Short List (Feature SC1) Subtable 

Speed Calling Long List (Feature SC2) Subtable 

Series Completion (Feature SCMP) Subtable 

Secondary Directory Number (Feature SDN) Subtable 

AT&T Line Studies (Feature SDY) Subtable 

Stop Hunt (Feature SHU) Subtable 

Subscribers Line Usage (Feature SLU) Subtable 

Special Billing Code (Feature SPB) Subtable 

Terminating Billing Option (Feature TBO) Subtable 

Warm Line (Feature WLN) Subtable 

Line Assignment Table 

Login Control Table 

Link Interface Module Card Inventory Table 

Link Interface Module Inventory Table 

Link Interface Module Port Inventory Table 

Line Attribute Table 

Link Interface Unit Inventory Table 

Link Identifier Table 

Line Module Inventory Table 

Line-to-Trunk Overlap Outpulse Table 

Line Module Ring Code Table 

Line Administration Table 

Line Balance Network Value Table 

TOPS Line Number Method of Coin Control Table 

Logical Metering Networks Table 

Line Circuit Inventory Table 

Line Inventory Extension Table 

Line Multi-Point Embedded Operations Channel Table 

Line Meter Names Table 

Local Number Portability Code Table 

Local Number Portability Options Table 

Local Number Portability Route Table 

Line Signaling System Table 

Signaling Type DELDIAL Subtable 

Signaling Type N5 Subtable 
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LNSIGSYS (NTLSO3) 
LNSIGSYS (NTLSO04) 
LNSIGSYS (NTLSO5) 
LNSIGSYS (NTLSO6 
Incoming) 
LNSIGSYS (NTLSO6 
Outgoing) 
LNSIGSYS (NTLSO7 
Incoming) 
LNSIGSYS (NTLSO7 
Outgoing) 
LNSIGSYS (NTLSO8 
Incoming) 
LNSIGSYS (NTLSO8 
Outgoing) 
LNSIGSYS (NTLSO9 
Incoming) 
LNSIGSYS (NTLSO9 
Outgoing) 
LNSIGSYS (NTLS10) 
LNSIGSYS (NTLS11 
Incoming) 
LNSIGSYS (NTLS11 
Outgoing) 
LNSIGSYS (NTLS14) 
LNSIGSYS (NTLS15 
Incoming) 
LNSIGSYS (NTLS15 
Outgoing) 
LNSIGSYS (NTLS16 
Incoming) 
LNSIGSYS (NTLS16 
Outgoing) 
LNSIGSYS (NTLS16 
Two-Way) 
LNSIGSYS (NTLS20 
Incoming) 
LNSIGSYS (NTLS20 
Outgoing) 
LNSIGSYS (NTLS22 
Incoming) 
LNSIGSYS (NTLS22 
Outgoing) 
LNSIGSYS (NTLS24 
Incoming/Outgoing) 
LNSIGSYS (WINKSIG) 
LNSMTCE 

LNTDM 

LNTHRSH 
LOGCLASS 

LOGDEV 

LOGINFO 

LPBKMEM 
LSCFLAGS 
LSPINFO 

LTCALLS 

LTCINV 

LTCPSINV 
LTCRINV 


Signaling Type NTLSO3 Subtable 

Signaling Type NTLSO4 Subtable 

Signaling Type NTLSO5 Subtable 

Signaling Type NTLSO6 Incoming Subtable 
Signaling Type NTLSO6 Outgoing Subtable 
Signaling Type NTLSO7 Incoming Subtable 
Signaling Type NTLSO7 Outgoing Subtable 
Signaling Type NTLSO8 Incoming Subtable 
Signaling Type NTLSO8 Outgoing Subtable 
Signaling Type NTLSO9 Incoming Subtable 


Signaling Type NTLSO9 Outgoing Subtable 


Signaling Type NTLS10 Subtable 
Signaling Type NTLS11 Incoming Subtable 


Signaling Type NTLS11 Outgoing Subtable 


Signaling Type NTLS14 Subtable 
Signaling Type NTLS15 Incoming Subtable 


Signaling Type NTLS15 Outgoing Subtable 
Signaling Type NTLS16 Incoming Subtable 
Signaling Type NTLS16 Outgoing Subtable 
Signaling Type NTLS16 Two-Way Subtable 
Signaling Type NTLS20 Incoming Subtable 
Signaling Type NTLS20 Outgoing Subtable 
Signaling Type NTLS22 Incoming Subtable 
Signaling Type NTLS22 Outgoing Subtable 
Signaling Type NTLs24 Incoming/Outgoing Subtable 


Signaling Type WINKSIG Subtable 

Line Maintenance Table 

Line Time Division Multiplex Table 

Lines and Thresholds Management Table 

Log Class Table 

Log Device Table 

Log Control Information Table 

Loopback Trunk Member Table 

Line Screening Code Flag Table 

Local Service Provider Information Table 
Logical Terminal Calls Table 

Line Trunk Controller Inventory Table 

Line Trunk Controller P-Side Link Inventory Table 
Line Trunk Controller Remote Inventory Table 
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LTCRPINV 
LTDATA 
LTDEF 
LTDSD 
LTGRP 
LTMAP 
LTPAUX 
LTPDEF 
MCCSNBEC 
MCCSOST 
MDESTIDX 
MDNGRP 
MDNMEM 
MDSACTN 
MDSLANG 
MDSOPT 
MFCACT 
MFCPROT 
MFCTRTIMT 
MILES 
MILESI 
MINCHG 
MINCHGI 
MLCCOPT 
MMAO-9 
MMCONF 
MNETATTR 
MOBCENT 
MODEMPRO 
MODMAP 
MODSET 
MOPTOPT 
MPBINV 
MPC 
MPCFASTA 
MPCLINK 
MPCLOGIN 
MPCLSET 
MPHCON 
MPHGRP 
MOLIMITS 
MRSANAME 
MSBINV 
MSBPSINV 
MSCDINV 
MSRCDATA 
MSFWLOAD 
MSGRTE 
MSILINV 
MSINV 
MTAHORIZ 
MTAMDRVE 
MTARF IDX 
MTARENUM 
MTARIFF 
MTAVERT 
MTCFAIL 
MTCTEST 
MTD 


Line Trunk Controller Remote P-Side Link Inventory Table 
Logical Terminal Data Table 

Logical Terminal Definition Table 

Line Test Desk Signal Distribution Table 

Logical Terminal Group Table 

Logical Terminal Mapping Table 

Line Test Position Auxiliary Commands Table 

Line Test Position Default Commands Table 

Mechanized Calling Card Service Non-Bell Exchange Carrier Table 
TOPS Mechanized Calling Card Service Originating Station Treatment Table 
Metering Destination Index Table 

Multiple Appearance Directory Number Group Table 
Multiple Appearance Directory Number Member Table 

TOPS Message Delivery System Actions Table 

TOPS Message Delivery System Language Table 

TOPS Message Delivery Service Options Table 
Multi-Frequency Compelled Signal to Activity Translation Table 
Multi-Frequency Compelled Protocol Tuples List Table 

MFC Activity to Extended Treatment Translation Table 
TOPS Mileage Table 

TOPS Mileage Inactive Table 

TOPS Minimum Charge Table 

TOPS Minimum Charge Inactive Table 

Mobile Line Class Code Compatible Table 

Minimum, Maximum Digits, and Ambiguous Code Table 

IBN Meet-Me Conference Table 

Metering Network Attributes Table 

Mobile Centrex Provisioning Table 

Modem Protocol Name Definition Table 

ITOPS Rating Charge Calculator Day Charge Modification Map Table 
ITOPS Rating Charge Calculator Time Charge Modification Set Table 
Mobile Incompatible Options Table 

Multi-Party Bridge Inventory Table 

Multi-Protocol Controller Table 

Multi-Protocol Controller Fast Applications Table 
Multi-Protocol Controller Link Table 

Multi-Protocol Controller Login Table 

Multi-Protocol Controller Linkset Table 

Multiple Position Hunt Console Table 

Multiple Position Hunt Group Table 

Maintenance Q-Limits Table 

List of Multi-Unit Message Rate Area Names Table 
Message Switching Buffer Inventory Table 

Message Switching Buffer P-Side Inventory Table 

Message Switch Cards Inventory Table 

Metering Source Data Table 

Message Switch Firmware Load Table 

PRA Facility Message Routing Table 

Message Switch Inter-MS Link Inventory Table 

Message Switch Inventory Table 

Metallic Test Access Horizontal Connection Table 
Metallic Test Access Minibar Driver Table 

Metering Tariff Index Table 

Metering Tariff Number Table 

Metering Tariff Table 

Metallic Test Access Vertical Connection Table 
Maintenance Failure Messages Table 

Maintenance Failure Messages Table 

Magnetic Tape Device Table 
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Short Name Title 

MTSIGSYS Hardware Metering for Trunks Signaling System Table 
MTRLNET Metering Logical Networks Table (MMP only) 

MTRLMOG Metered Originator Groups Table (MMP only) 

MTRMOTS Metered Originator Tariff Sets Table (MMP only) 
MTRNAMES Meter Names Table (MMP only) 

MTRNETIF Metering Network Dependent Information Table (MMP only) 
MTRSYSPM Metering System Parameters Table (MMP only) 
MTRTARIF Metering Tariffs Table (MMP only) 

MTRTTS Metering Time-and-Date Tariff Sets Table (MMP only) 
MUMRMBI Multi-Unit Message Rate Message Billing Index Table 
MUMRTAB Multi-Unit Message Rate Screening Table 

MWDATA Milliwatt Data Table 

N7CLLDGT N7 (CCITT No.7) Called Global Title Table 

N7CLLGGT N7 (CCITT No.7) Calling Global Title Table 

NACDGRP Network Automatic Call Distribution Group Table 
NARDATA Network Access Registers Data Table 

NATDGTAN National Digit Analyser Table 

NBECCODE Non-Bell Exchange Company Code Table 

NCOS Network Class of Service Table 

NCSADDR Network Control System Address Table 

NCSAPPL Network Control System Application Table 

NETATTR Network Attributes Table 

NETJUNCT Network Junction Group Table 

NETNAMES Internal Logical Network Names Table 

NETTOPRT NETINFO to Partition Number Mapping Table 

NETTOSTS Network Information Table 

NETWORK Network Assignment Table 

NIUINV Network Interface Unit Inventory Table 

NLUPCLLI Nailed-Up Connection CLLI Table 

NMSDATA Network Message Service Data Table 

NNASST Node Number Assignment Table 

NO6BDXLA CCITT No.6 Band Translation Table 

NO6LINKS CCITT No.6 Signaling Links Table 

NO6LKSET CCITT No.6 Link Set Table 

NO6RTSET CCITT No.6 Route Set Table 

NO6STP CCITT No.6 Signal Transfer Point Table 

NO6STPBD CCITT No.6 Signal Transfer Point Table 

NO6TKMEM CCITT No.6 Trunk Member Table 

NOPADDR Network Operations Protocol Address Table 

NOPAPPLN Network Operations Protocol Applications Table 
NOPDEST Network Operations Protocol Destination Table 
NOPUSERS Network Operations Protocol Users Table 

NPACAT Serving NPA Category Digit Table 

NPACHECK TOPS NPA Check Table 

NPASPLIT Numbering Plan Area Split Management Table 

NPDIGMAP Number Portability Digit Mapping Table 

NPENDING Number Pending Table 

NPRESERV Number Pooling Reserved Number Marketing Table 
NSCANNS Number Service Code Announcement Table 

NSCCARR Number Service Code 800 Plus Southbound Carrier ID Validation Table 
NSCCODE Number Service Code Table 

NSCDEFS Number Service Code Database Response Timeouts Table 
NSCHEAD Number Service Code Head Table 

NSCRTE Number Service Code Route Table 

NSCSCRN Number Service Code Screening Table 

NSCSNPA Number Service Code Special Area Codes Table 

NS IMAP Non-Specified Information String Map Table (MMP only) 
NSTAFAS Night Service Trunk Answer from Any Station Table 
NTCLANGS Notification of Time and Charge Languages Table 
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Short Name Title 

NUMBFMT ITOPS Position Display Number Formatting Table 

NUMDIGS Number of Digits Table (MMP only) 

NWMAOCR Network Management Automatic Out of Chain Reroute Table 

NWMCLLI Network Management CLLI Table 

NWMIDOC Network Management Internal Dynamic Overload Control Table 

NWMPPLN Network Management Preplan Control Table 

NWMSC Network Management Scan Group Table 

NWMSCPT Network Management Scan Point Table 

NWMSD Network Management Signal Distributor Group Table 

NWMSDPT Network Management Signal Distributor Point Table 

NX64MEM NX64 Member Table 

OACAUPRF Operator Services Systems Advanced Intelligent Network (OSSAIN) Cause 
Profile Table 

OACNNPRFE OSSAIN Connecting Profile Table 

OACTLDEF Control List Definition Table 

OADSCPRF OSSAIN Post Disconnect Profile Table 

OADTFPRF OSSAIN Dual-Tone Multi-Frequency Profile Table 

OAFUNBLK OSSAIN Function Blocking Table 

OAFUNDEF OSSAIN Function Definition Table 

OAFNDISP OSSAIN Function Disposition Table 

OAINCTLA OSSAIN Control List Assignment Table 

OAINPARM OSSAIN Parameters Table 

OAINPRE OSSAIN Pre-Processing Table 

OAINRTE OSSAIN Route Table 

OANODINV OSSAIN Node Inventory Table 

OANODNAM OSSAIN Node Name Table 

OATLKPRE OSSAIN Talking Profile Table 

OATPRFIX OSSAIN Trigger Profile Table 

OASESNPL OSSAIN Session Pool Table 

OAVLMAP OSSAIN Node Inventory Table 

OCCINFO Equal Access Other Common Carrier Information Table 

OCCMAP Equal Access List of Other Common Carrier Mapping Table 

OCCNAME Equal Access List of Other Common Carrier Names Table 

OCCRDIG Equal Access Other Common Carrier R-Digit Table 

OCCSRV Equal Access Other Common Carrier Service Data Table 

OCCTSINT Equal Access Other Common Carrier Traffic Separation Intersection Table 

OCDLGRP Operator Centralization Data Link Group Table 

OCGRP Operator Centralization Group Table 

OCHOST Operator Centralization Host Table 

OCHOSTQ Operator Centralization Host Queue Table 

OCIPDL Operator Centralization Internet Protocol Map 

OCOFC Operator Centralization Office Table 

OCPARMS Operator Centralization Parameter Table 

OFC Outbound Facility Table 

OFCAUT Office Auto-Provisioning Table 

OFCCODE Office Code Table 

OFCHEAD Office Code Head Table 

OFCRTE Office Code Route Table 

OFRT Office Route Table 

OFRT (AFR) Automatic Flexible Routing (Selector AFR) Subtable 

OFRT (CND) Calling Number Delivery (Selector CND) Subtable 

OFRT (DCRT) Dynamically Controlled Routing (Selector DCRT) Subtable 

OFRT (DN) Directory Number (Selector DN) Subtable 

OFRT (ISA) Integrated Service Access (Selector ISA) Subtable 

OFRT (MEM) Trunk Group Member (Selector MEM) Subtable 

OFRT (MN) Route Selector MN (Selector MN) Subtable 

OFRT (N) Route Selector N (Selector N) Subtable 

OFRT (N2) Route Selector N2 (Selector N2) Subtable 

OFRT (NODE) Route Selector NODE (Selector NODE) Subtable 
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Short Name Title 

OFRT (NOT) Route Selector NOT (Selector NOT) Subtable 
OFRT (NPOS) Route Selector NPOS (Selector NPOS) Subtable 
OFRT (NPOSDN) Route Selector NPOS (Selector NPOSDN) Subtable 
OFRT (QH) Queue Head (Selector QH) Subtable 

OFRT (RT) Retranslate (Selector RT) Subtable 

OFRT (RX) Retranslate IBN (Selector RX) Subtable 

OFRT (S) Route Selector S (Selector S) Subtable 

OFRT (SG) Super Trunk Group (Selector SG) Subtable 
OFRT (ST) Same Subtable (Selector ST) Subtable 

OFRT (SX) Route Selector S (Selector SX) Subtable 

OFRT (T) Route Selector T (Selector T) Subtable 

OFRT (TC) Route Selector TC (Selector TC) Subtable 
OFRT (TPBX) Route Selector TPBX (Selector TPBX) Subtable 
OFRT (TRMT) Treatment (Selector TRMT) Subtable 

OFRT (TS) Two-Stage (Selector TS) Subtable 

OFRT (UOP) Uniform Outpulsing (Selector UOP) Subtable 
OFR2 Office Route-2 Table 

OFR3 Office Route-3 Table 

OFR4 Office Route-4 Table 

OFCTIID Office Trigger Item identifier Table 

OFRTMAP ISDN OFRT Route Reference Table 

OFRTMA2 ISDN OFR2 Route Reference Table 

OFRTMA3 ISDN OFR3 Route Reference Table 

OFRTMA4 ISDN OFR4 Route Reference Table 

OGTMPKEY Outgoing Trunk Multi-Purpose Key Table 
OGTSPKEY Outgoing Trunk Single-Purpose Key Table 
OHBTADMN Off-Hook Balance Testing Administration Table 
OHBTINV Off-Hook Balance Testing Inventory Table 


OHIP Office Hardware Inventory Package Table 


OHIPBULK Bulk Hardware Inventory Package Table 

OIASTART Open Information Access Automatic Session Start Table 
OICBC Office Identification Code Billing Code Table 
OLNSDARS OLNS Directory Assistance Billing Restriction Table 
OLNSDFLT OLNS Default Table 

OLNSEQDP OLNS Service/Equipment Display Table 

OLNSERR OLNS Error Table 

OLNSLANG OLNS Language 

OLNSRSDP OLNS Originating Line Number Screening Restricted Billing Display Table 
OLNSTARS OLNS Toll and Assist Billing Restriction Table 
OMACC Operational Measurements Accumulator Table 

OMACCESS Operational Measurements Group Access Table 
OMACCFLD Operational Measurements Accumulator Field Table 
OMACCGRP Operational Measurements Accumulator Groups Table 
OMACCKEY Operational Measurements Accumulator Key Table 
OMACCTOT Operational Measurements Accumulator Total Table 
OMDEV Operational Measurements Device Table 

OMGRPORD Operational Measurements Group Order Table 

OMPRT Operational Measurements Printer Table 

OMREPORT Operational Measurements Report Table 

OMTAPE Operational Measurements Output Recording Table 
OMTHRESH Threshold Alarms Table 

OMTOTAL Operational Measurements Totaling Table 

OOCBILL 0OC Overseas Billing Restrictions Table 

OPENANTI Open Numbering Plan ANI Table 

OPMINV Outside Plant Module Inventory Table 

OPRCMPLX Table Operator Complex and Unit ID Table 

OPRDAT TOPS Operator Data Table 

OPRINFO Operator Information Table 

OPRPRFX ITOPS Operator Automatic Prefixing Table 
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Short Name Title 

OPRTRANS TOPS Operator Translations Table 

OPTCTL Option Control Table 

OPTOPT Incompatible Options Table 

OPTTREAT Optional Treatment Table 

OQCOPROF OSSAIN QMS Call Queue Profile Table 

ORIGRC TOPS Point-to-Point Rating Originating Rate Centers Table 
OSCVLGRP OSSAIN Centralization Voice Link Group Table 
OSIPARMS Open Systems Interconnect Parameter Table 
OSIROUTE Open Systems Interconnect Routing Table 

OSNCCAP Operator Services Network Capability Table 
OSSANNS Operator Services System Announcements Table 
OSSCAT ANIID Mapping for TOPS Trunk Groups with OSS Table 
OSSPROV Operation System Support Provisioning Table 
OVNTRNSL Overseas Number Translation Table 

OVRO-9 Overseas Route Tables 

OVRMAP Overseas Route Index Mapping Table 

OVSBILL TOPS Overseas Billing Restrictions Table 

OVSCC TOPS Overseas Credit Card Table 

OvsccYyL TOPS Overseas Credit Card Year Letter Table 

OVSRS TOPS Overseas Rate Step Table 

OVSRSI TOPS Overseas Rate Step Inactive Table 

OWATZONE OUTWATS Zone Table 

OWNER Owner Table 

OWNTAB Ownership Table 

PACMAN IBN ESN Protocol Analysis and Code Manipulation Table 
PADDATA Pad Data Table 

PADNDEV Patch Administration Device Table 

PARSDENY TOPS Personal Audio Response System Denial Table 
PARSMBR TOPS Personal Audio Response System Member Table 
PATALARM Patch Alarm Table 

PATCHOPT Patcher Options Table 

PATCTRL Patch Control Table 

PATNS Patch Nodeset Table 

PATSET Patch Set Table 

PCIC Phantom Carrier Identification Code Table 

PCITRK Pre-Select Carrier Identification Trunk Table (MMP only) 
PCIXLA Pre-Select Carrier Identification Translation Table (MMP only 
PECINV Product Engineering Code Inventory Table 

PFCTRL Power Feature Control Table 

PFXTREAT Prefix Treatment Table 

PHDS1 Packet Handler to DS-1 Connection Table 

PHINFO Packet Handler Information Table 

PHINV Packet Handler Inventory Table 

PICNAME Primary Inter-LATA Carrier Name Table 

PILOTGRP Pilot Groups Table 

PINDATA Personal Identification Number Data Table 

PLATAB Physical Link Adapter Table 

PMEXCEPT Peripheral Modules Excepted Table 

PMLOADS Peripheral Module Loads Table 

PMNODES Peripheral Module Nodes Table 

PNINFO Ported Number Routing Information Table (MMP only) 
PNSCRN Ported Number Screening Table (MMP only) 

PODPATTR Public Office Dialing Plan Attributes Table 
POECNM Path of Entry Characteristic Name Table 

POECSCRN Path of Entry Characteristic Screening Table 
PORTNUMS Portable Numbers Table 

POSITION Position Table 

POSNAME List of Position Names Table 


54 


Experimenting with a Stellex YIG Oscillator 


Overview 


Stellex 6755-726 (Endwave MY01210) tunable mini-YIG oscillators are starting to show up on 
Ebay for around $20 to $40. Most of these YIGs cover the X-band frequency range, and without 
any tuning current are usually centered around 9 GHz. They are able to tune up or down 
approximately 1 GHz from this center frequency. YIG oscillators are just like regular Voltage 
Controlled Oscillators (VCO), except they require a constant tuning current rather than a constant 
voltage. This makes the YIG's driving circuit a little more complicated, but the final result will be a 
stable RF signal with low phase noise and around +12 dBm of output RF power. 


The driver circuit covered here will be a slightly altered version of the one shown in the RSGB's 
International Microwave Handbook. The concept of the YIG driver schematic is to convert a 
constant control voltage into a constant current that is running through one of the YIG's tuning 
connections. The Stellex 6755-726 YIG has a tuning sensitivity of around 5 MHz per milliamp of 
current flowing through its "tune" connection. Postive current flow increases the output frequency, 
while negative current flow reduces the output frequency. What this means, is that in order to tune 
a 9 GHz YIG up to the 10 GHz range, around 200 mA of positve current will need to flow through 
the YIG's tuning lines. The circuit to do this will need to be very stable (and low-noise) in order to 
maintain a clean and stable RF output. For this circuit, we'll be using LM627 (or OP27) low-noise 
op—amps to control a IRF510 MOSFET which is connected in series with the YIG's tuning lines. A 
simple feedback network will measure the voltage drop across a resistor and the op—amp's output 
will control the gate of the MOSFET which, in turn, regulates the current flowing through the YIG's 
tuning lines. Since the current limiting resistor used in this driver circuit is 10 ohms, the voltage drop 
across it will be 1 volt for every 100 mA of current flowing through the respective tuning line. As the 
voltage input to the op—amp's non-inverting pin increases, the current passed by the IRF510 will 
also increase. For example, say we measure 2 volts across the 10 ohm limiting resistor. This 
works out to that particular YIG line drawing 200 mA of current. This can be used as a test point to 
quickly check that the YIG's currents are at their proper settings. 


This model YIG also has the ability to be Frequency Modulated (FM) with a separate set of tuning 
lines. Modulating the YIG is basicaly the same as tuning the YIG, except the RF frequency range 
per milliamp of current is much smaller and the modulating signal will need to be on a DC offset 
when applied to the controlling op—amp. Bewere that the YIG's FM tuning lines can NOT handle 
alot of current flowing through them. You should try to keep the modulating current well under 200 
mA. Note that using the FM driver with the YIG is optional if you just wish to have a CW PF source. 


Several versions of this YIG oscillator are available with an external PLL sythesizer for better 
frequency stability. John Miles, KE5FX, has some excellent documentation and PLL source code 
on his website at: www.thegleam.com/ke5fx/stellex.htm. It's a little more complicated than 
the free-running YIG driver shown here. 
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Pictures & Construction Notes 
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Mounting of the YIG and the tuning driver circuit board. 


The YIG is mounted on a small piece of art foam to help avoid any microphonics from 
vibrations. This stock Stellex 6755-726 YIG had a center frequency of 9.142 GHz with no tuning 
current. Its RF output power was +11.6 dBm (14 mW). 


On the upper-right of the driver circuit board is a LM317 voltage regulator which provides a stable 
+8.5 VDC from the +12 VDC input. A LTC 1044 negative voltage inverter generates the -8.5 VDC 
for the negative rail on the op—amps. The tuning LM627 op—amp is on the lower portion of the 
circuit board with a multiturn 5 kohm potentiometer for main frequency adjustment. 


The Stellex 6755-726 YIG with this driver circuit could tune up to around 10.4 GHz. The YIG will 
get farily warm, so it's probably best not to run it at its full tuning current, so back it down to around 
10.0 to 10.1 GHz maximum. 


Note that this driver and modulating circuit is still experimental and the first version broke into 


oscillation and required a little bit of tweaking to work properly. When | can get a chance to view the 
RF output on a spectrum analyzer, I'll be sure to document any necessary changes. 
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Alternate view. 


The LM317 voltage regulator should have been mounted to a heatsink as it can get quite warm. 


The pin-out on the Stellex 6755-726 YIG as shown, with pin 1 on the left: 


Pin Function Wire Color 
1 +8.5 VDC Bias (120 mA) Red 

2 Ground Black 

3 Tune + Violet 

4 Tune — Orange 

5 FM + Yellow 

6 FM - Gray 


The "Wire Color" refers to the hook-up wires attached to a stock Stellex YIG if you purchase them 
off eBay. 


Note that the violet wire (Tune +) has a series 15 ohm resistor. 
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Addition of the FM driver circuit board. 

On the FM driver board, the potentiometer to the farthest left controls the DC offset to the op—amp, 
which is the main control of the YIG's FM tuning line. The FM tuning line of the YIG can only handle 
200 mA or so maximum current so be very careful when tuning this offset. The other potentiometer 
controls the amplitude of the incoming modulating signal. 

You may wish to add a 250 mA fuse in series with the YIG's FM tune line. 


Do to constant tweaking, the component values in the pictures and the schematic may not be the 
same. The schematics at the end of this article will have the correct values. 
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Finishing touches. 


This includes the addition of a feed—through SMA connector and a short little SMA jumper cable for 
the RF output. A RCA jack was added for supplying the incoming modulation voltage. A 
feed—-through capacitor is used for the incoming +12 VDC line. The two IRF510 MOSFETs are 
mounted to the side of the case with non-conductive isolation pads and nylon hardware. 
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Completed YIG driver, alternate view. 


Note the 10 uF capacitor added to the gate line of the left-side IRF510 MOSFET. This was added 
to swamp a large oscillation occurying on the MOSFETs' gate line. This will need to be looked into 
further. 
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Completed case overview. 


From left-to-right, +12 VDC input, modulating signal, and the RF output. 
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Bonus 


Police sorry for puppy 
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Innocent: Taysite Police force's crime-~busting dog, Rebe 


DEAR EUROPE, 


This is why we don't listen to your thoughts on how to deal 
with terrorism. —Sincerely, America. 
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End of Issue #73 





Editorial and Rants 


: 


> \ 


a 





"When the people fear their government, there is tyranny; when the government fears the 
people, there is liberty." 


—-— Quote from Thomas Jefferson (1743-1826), third President of the United States of America 
and principal author of the Declaration of Independence. 


66 


Apparently, the latest thing to piss off liberals is this man's truck. Somehow a truck can be "racist," 
or whatever cute term the media is using these days. 


GAP VIRGINIA “EH 
B LACY88 





This is funny, because in certain areas of New York City, the loony kikes patrol (Shomrim) 
neighborhoods in order maintain their Jewish supremacy. They even have fake patrol vehicles 
which eerily look like rea/ NYPD police cars. Shomrim is NOT a law enforcement organization, but 
merely a group of Jewish volunteers. 





Just don't count on these vehicles ever being described as "racist" by the mainstream media! 


And, yes, those are parking tickets under the windshield wiper... 
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Before the attempted NYC Times Square bomber was caught, the brain-dead liberal Susie Madrak 
at Crooks and Liars wrote: 


"You know, | don't want to jump to conclusions here, because that would make 
me too much like Matt Drudge. But if the car bomber was indeed a white guy 
in his 40s who didn't know the difference between ammonium nitrate and plain 
old fertilizer, I'm thinking it's gotta be a [Glenn] Beck Patriot who was trying to 
water the tree of liberty with... the blood of random Times Square tourists." 


(crooksandliars.com/susie—madrak/it-would—be—irresponsible—not—specula) 


Of course, after it was found out the bomber was a Pakistani—born Muslim (shock), and probably an 
Obama supporter, she quickly changed her tune: 


"Isn't it just a little wacky that some people are more interested in who they get 
to blame than in the fact that someone tried to blow up Times Square?" 


(crooksandliars.com/susie—madrak/even—blind—squirrel—finds—occasional) 
LOL! But that's not as bad as Robert Dreyfuss for The Nation, who wrote: 


"It may be that the Pakistan-based Taliban, the Tehrik-e Taliban Pakistan 
(TTP), has quietly established a Connecticut franchise while we weren't 
looking. That's possible. But it seems far more likely to me that the 
perpetrator of the bungled Times Square bomb plot was either a lone nut job or 
a member of some squirrely branch of the Tea Party, anti-government far 
right. Which actually exists in Connecticut, where, it seems, the car's license 


plates were stolen." 


(www.thenation.com/blogs/dreyfuss/557726/a_connecticut_taliban_in_bloomberg_s_court) 


He quickly had that entire story removed from their website! Change! 





Students Protest Planned School Budget Cuts 
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From a school walk-out to "protest" budget cuts in New Jersey. 


Don't you just Jove students (holding BlackBerrys) complaining about their "free" breakfast and 
lunch school programs? 


This is more evidence that these students, or more likely — their fat Black mammies, are just too 
lazy to feed their own damn kids and need the taxpayer to babysit them. 
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Stumbled upon this article just recently. It's a pretty good read... 


Where Will We Go When America Becomes Like Everywhere Else? 


July 20, 2009 — From: 004eeb5.netsolhost.com 
By Paul Ibrahim 


| immigrated to America because it was supposed to be special. And it is. Few nations have 
sincerely grown on the basis that God grants every human being freedom and basic rights, and that 
as a matter of convenience, the people will delegate only some of their powers to achieve 
legitimately communal functions such as building roads, enforcing contracts, resisting crime and 
fighting off foreign threats. 


As true and obvious as such a principle should be, it is sadly rare and unique in the modern 

world. It is therefore no surprise that America's distinctive non-interference with God-given rights 
has attracted many millions of immigrants from around the world, and that its capitalist system has 
allowed it to become the most prosperous and powerful country in the world. 


Yet what is astounding is that, instead of continuing on the track that has made America flourish to 
an unprecedented extent, the people have been electing governments that rewrite contracts instead 
of enforcing them, that tax the people to a degree beyond the wildest imagination of the founding 
fathers, and that design enormous social experiments as instruments that can be used to infringe on 
individual rights and freedoms. In other words, through their politicians, Americans are trying to 
make America like every other country in the world. 


Does it not strike them that America is a nation of immigrants precisely because just about every 
other country has been getting it wrong in just about every era? And if America becomes like those 
countries, where are we, immigrants and descendents of immigrants who escaped those other 
countries, supposed to go next? 


The fact is that big government of every flavor is available just about everywhere else in the world 
for Americans who so embrace it. The socialists can collectively enjoy mediocrity in Europe, and 
the theocrats can have a blast in the Middle East. The communists can reap the fruits of their 
ideology in North Korea, and the monarchists still have reliable options around the globe. 


But where would the rest of us, who actually wish to retain the freedoms given to us by God, and 
who are willing to work hard in exchange for rewards without government interference, end up if 
America went the way of the rest of the world? There is nowhere else. 


Now America has had the blessing of being divided into relatively self-governing states, a rare 
luxury that has allowed Americans to vote with their feet by abandoning weary states with big, 
intrusive governments, and embracing the prosperous states most loyal to small government 
ideals. This movement has been an incredible source of checks and balances among the states. 


Researchers have found that between 1998 and 2007, more than 1,100 people moved from the 
nine highest income-tax states (the bluest of states) mostly to the nine tax—haven states every 
single day. This movement is consistent with the fact that the recipient group of states created 89 
percent more jobs and 32 percent faster personal income growth during that period. Indeed, those 
states that have the highest taxes now also face the biggest budget gaps due to the exodus of their 
tax base (see California, New York, etc.) 
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Assuming that ACORN does not "help out" too much with the 2010 census, Americans’ embrace of 
small-government states will be reflected by the reapportionment of congressional seats. At this 
point, Georgia, Nevada, South Carolina, and Utah are expected to gain one seat, Florida one or two 
seats, Arizona two seats, and Texas, with its pro-growth policies and rejection of nanny statism, 
four seats. That makes for five solidly red states and two swing states. 


On the other hand, Illinois, lowa, Louisiana, Massachusetts, Michigan, Minnesota, Missouri, New 
Jersey, New York and Pennsylvania are each expected to lose one seat, and Ohio two. All of these 
were blue states in 2008, with the exception of Missouri (which went red by roughly 0.001 percent of 
the vote), and Louisiana, which has endured a serious loss of population due to Hurricane Katrina. 


Those who move include people in all economic brackets — the "rich" make their money and their 
job creation with them, and those they employ follow. 


But when the federal government attempts to erase all differences between the states through 
massive federal taxes and spending, Americans' ability to choose among 50 laboratories becomes 
decreasingly feasible. What's the point of moving between states if you will face the same exact 
taxes and policies in each? 


And this is what the federal government is doing. It is eliminating our choices within the U.S. by 
giving us one giant central government that we cannot escape. We've already established that 
foreign countries are out of the question. So when America descends to their level, where will we 
go? 


Texas Governor Rick Perry has already hinted at secession, and the libertarian movement, through 
the Free State Project, is already coalescing in New Hampshire to give our founders’ vision one last 
stand. One can only hope that it won't get to that— but it's not looking so bright. 
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